fix(antigravity): read turn boundaries from the transcript, not file mtime

[JackFurton]

Every tool call played "Job's done!" then "Right away!". Mtime inference read a long tool call as completion, and the write that followed it as a new prompt.

Boundaries now come from transcript.jsonl records: USER_INPUT/USER_EXPLICIT is a prompt, PLANNER_RESPONSE with tool_calls is work in flight, and one with prose and none is the final answer. Idle timeouts are off for sessions that have a transcript. Sessions without one keep the mtime fallback, now 45s.

Two things only real transcripts showed:

• A PLANNER_RESPONSE with no tool_calls is a turn end only if it also has prose. Antigravity emits empty ones beside every ERROR_MESSAGE while retrying a rate limit, giving 18 Stops in an 80-record session against 6 real ones.
• transcript_full.jsonl is byte-identical to transcript.jsonl, so the transcript* glob would have doubled every event once records drove them.

Replaying 33 transcripts gives 124 acknowledgements for 124 prompts.

Permission prompts

Four fixes, none of which unit tests could have found. Running this against live Antigravity is what surfaced them:

• cli.log is a symlink into log/cli-<timestamp>.log, retargeted at every launch, so watching the symlink's own directory never sees a write. Prompts never fired at all.
• Antigravity holds the log open and flushes in batches. Filesystem events arrived minutes late or never, so the log is polled once a second, and polled rather than observed so one offset has one reader.
• A flushed batch usually contains prompts already answered. Only a batch that ends still unanswered sounds, and once. Replaying each Surfacing line delivered a burst of notifications for prompts answered minutes earlier.
• Offsets are keyed by resolved path; the same file otherwise arrives under two names.

Attribution is the most recently active conversation, the surfacing line carrying no conversation id, seeded from the newest transcript at startup so a watcher started mid-session is not silent until the user types. Two concurrent sessions can misattribute one, worst case a sound against the wrong tab.

Notifications claimed to be Claude Code

The watcher is a daemon, so its working directory is /, and it passed that as every event's cwd. peon.sh cannot make a project name out of / and falls back to labelling anything non-Codex claude, so every Antigravity banner was titled that, with no way to tell which workspace it came from.

The workspace now comes from the conversation's own conversations/<guid>.db, which stores it as a file:// URI in trajectory_metadata_blob, falling back to cache/last_conversations.json. Reading the database is what makes a resumed session resolve: the cache holds only the newest conversation per workspace, so anything older missed. Across 46 real conversations this resolves 37. The 9 it does not are default-cli-project sessions started outside a workspace, which record no path anywhere; those fall back to home rather than to the misleading claude label.

Claude Code has no equivalent problem because it passes cwd in the hook payload. Antigravity has no hook API, so the watcher has to recover it.

The rest

Command failures play task.error, which needed tool_name and error plumbed through the watcher protocol since that is what peon.sh gates on.

resource.limit stays unreachable, peon.sh routing it only from PreCompact, so rate limits land on task.error. Subagent events are unwired: peon.sh tracks subagents by session-id relationships the watcher does not model, and INVOKE_SUBAGENT appears once across 33 transcripts. Both felt like the right call, but I would take either on if you disagree.

Also: gemini.sh and gemini.ps1 mapped AfterTool exit 0 to Stop, with the bats and Pester tests asserting that updated; install.sh never shipped antigravity-watcher.py, so the adapter died on its own preflight; peon status --verbose now lists Antigravity; the watcher's stderr appends to the adapter log rather than truncating it, the LaunchAgent having the same file open.

The dispatch loop in antigravity-py.sh is a function so it can be tested, reading tab-delimited fields on one line. Field-per-line aborts under set -e, because $() strips trailing newlines and the read for an absent tool_name hits EOF.

Verified on a real machine

Installed on macOS as a LaunchAgent against live Antigravity. A turn with one failing command:

New session: f227406a
User prompt: f227406a
Command failed (127): f227406a

A flushed batch of three prompts where two were already answered fires exactly one PermissionRequest; the same batch arriving while one is already pending fires none.

python3 -m unittest tests.test_antigravity_watcher            73 passed (was 14)
bats tests/antigravity.bats antigravity-py.bats gemini.bats   32 passed, 0 failed
bats tests/peon.bats                                         455 passed, 6 failed locally

Those 6 pass on CI and fail only on my machine, where a real ~/.codex and terminal state leak into them.

Version bumped to 2.38.0 with a CHANGELOG entry. No tag pushed.

[vercel]

@JackFurton is attempting to deploy a commit to the Gary Sheng's projects Team on Vercel.

A member of the Team first needs to authorize it.