Detect sandbox mode and network in statusline example

[raybell-md]

What

Makes the example statusline detect terminal sandbox mode even though the statusLine payload doesn't currently report it.

Why

As of agy 1.0.6, agy --sandbox enables the terminal sandbox but does not set .sandbox.enabled in the statusLine payload — it stays false. As a result the example's sandbox badge always reads sandbox off even when running under --sandbox.

I confirmed there's no other clean signal available to a statusLine script:

• Payload — .sandbox.enabled stays false; no populated execution_mode field either.
• Environment — sandbox env vars (_AGY_SBOXSERVE, SANDBOX) are not exported to the statusLine process.
• Process tree — the statusLine process is reparented to init, so its parent command line can't be inspected.

The only reliable signal is the session log line --sandbox: enabling terminal sandbox for this session, which ~/.gemini/antigravity-cli/cli.log symlinks to.

How

Keep .sandbox.enabled as the primary source and, only when it's not already true, fall back to grepping the current session log. This means the workaround self-corrects automatically once the payload field is populated upstream — no follow-up change needed.

if [ "$SANDBOX" != "true" ]; then
  SANDBOX_LOG="$HOME/.gemini/antigravity-cli/cli.log"
  if [ -r "$SANDBOX_LOG" ] && grep -q 'enabling terminal sandbox' "$SANDBOX_LOG" 2>/dev/null; then
    SANDBOX="true"
  fi
fi

Caveat

This is an interim workaround, not a real fix. cli.log always points at the newest session, so a stale refresh from an older non-sandbox terminal could theoretically read a newer sandbox session's log. The proper fix is for agy to populate sandbox.enabled (and/or execution_mode) in the payload — tracked in #321. Happy to drop this if you'd prefer to fix it at the source instead.

Testing

• bash -n passes.
• With a session log containing the sandbox line + payload sandbox.enabled=false → renders sandbox ON.
• With no sandbox line in the log → renders sandbox off.

---

Update: also show sandbox network mode (closes #399)

Added a second commit that surfaces the network mode in the badge, addressing the confusion reported in #399 where users couldn't tell whether sandboxAllowNetwork had taken effect.

Same shape as the .enabled workaround above. The payload's sandbox object only carries .enabled — there is no .sandbox.allow_network field — and the session log has no network-specific line. So the badge reads the authoritative sandboxAllowNetwork from settings.json, while still preferring .sandbox.allow_network from the payload when present (self-corrects upstream, #321).

The badge now reads sandbox ON (net) or sandbox ON (no-net).

Testing

• bash -n passes.
• Payload allow_network=true/false → (net)/(no-net).
• Payload sandbox absent + sandboxAllowNetwork:true in settings.json → (net); false → (no-net).
• Payload allow_network=true overrides settings → (net).
• All paths exit 0 under set -euo pipefail.

[weby-homelab]

Hi @raybell-md! I also addressed sandbox state formatting in my responsive statusline script, providing distinct badges for ON (net), ON (no-net), and OFF based on the JSON payload.

Feel free to check out the implementation or use it as a reference:
https://github.com/weby-homelab/antigravity-cli-statusline

Community discussion: #397