Gemini remote sessions stuck after context overflow; no recovery path (Antigravity transition)

[heavygee]

Summary

Gemini remote sessions can become permanently stuck after resume: every new prompt fails with The input token count exceeds the maximum number of tokens allowed 1048576, with no recovery path. HAPI surfaces the error but does not compact/retry (unlike Codex).

Observed on session "hapi - gemini windows installer" (HAPI b0a7208e-f35e-410a-b130-00adbf3dc040, Gemini dd9982b5-b3e6-4c1c-a9ab-87e4e7cfdbf3, gemini-cli 0.43.0).

Reproduction

1. Run a long Gemini remote session with many tool calls (especially large shell output).
2. Resume the session (hapi gemini --resume <id> --hapi-starting-mode remote).
3. Send any new message.

Result: Immediate API rejection at the 1,048,576-token hard limit. Subsequent model switches can mask the failure with quota errors.

Root cause (evidence)

Layer	Finding
HAPI DB	~427 messages, ~161 KB (not bloated)
Gemini CLI transcript	903 MB JSONL at ~/.gemini/tmp/hapi/chats/session-*-dd9982b5.jsonl
Trigger	grep -r "HUB_URL" . from repo root → 4.6 MB shell output
Amplification	Gemini CLI stores cumulative toolCalls with full outputs per turn; the 4.6 MB blob was duplicated 152× across turns (~228M estimated tokens vs 1M limit)

The context error is real, not a miscount — but recovery is blocked by missing HAPI handling and upstream compression limits.

HAPI gaps (fix regardless of backend)

1. No context overflow recovery — geminiRemoteLauncher.ts logs and surfaces errors; Codex has compact-and-retry in codexRemoteLauncher.ts.
2. No /compact handling for Gemini remote sessions.
3. No context budget UI for Gemini — web/src/chat/modelConfig.ts returns null for non-Claude/Codex flavors.
4. Local scanner bug — cli/src/gemini/utils/sessionScanner.ts JSON.parse()s the entire transcript file, but Gemini writes JSONL (fails on line 2).

Antigravity CLI transition

Google is transitioning Gemini CLI to Antigravity CLI (June 2026 consumer cutoff). That migration may change the harness, but it is not guaranteed to fix:

• cumulative tool-output bloat in persisted sessions
• compression failing when context is already over limit
• HAPI-specific resume/recovery behavior

HAPI already has an Antigravity path (~/.gemini/antigravity-cli). This issue tracks fixes that should apply to both current Gemini ACP integration and the Antigravity backend — session recovery, clearer errors, context UI, and JSONL-safe local scanning.

Upstream references (same failure modes)

• google-gemini/gemini-cli#7784 — /compress fails when history is already too long
• google-gemini/gemini-cli#8609 — context overflow + broken compress recovery
• google-gemini/gemini-cli#20933 — metadata bloat (thoughtSignature) pushing requests over limit
• Gemini CLI config: ui.compactToolOutput, model.compressionThreshold

Proposed HAPI work

• Detect token-limit errors in geminiRemoteLauncher.ts; attempt compact/recovery (mirror Codex) or instruct user to start fresh
• Distinguish context exhaustion from quota/rate-limit errors in user-facing messages
• Add Gemini context budget to web status bar
• Fix sessionScanner.ts to read JSONL line-by-line
• Validate same behavior on Antigravity CLI backend when HAPI switches default harness

Operator mitigation (applied locally)

• Archived poisoned transcript (~903 MB)
• Set ui.compactToolOutput: true, model.compressionThreshold: 0.5, model.maxSessionTurns: 100 in ~/.gemini/settings.json
• Do not resume poisoned Gemini session IDs — start fresh

[heavygee]

Upstream tracking: tiann#711

Filed on upstream with expanded Antigravity migration decision context (shared harness, same stuck-resume risk unless HAPI adds backend-agnostic recovery).