fix(browser): update Gemini web protocol and fallback handling

[mpeter]

Summary

• refresh Gemini web StreamGenerate requests to the current 97-field payload and extension headers
• update current model hashes/selections for Flash-Lite, Flash, Pro, and Deep Think
• reject upstream errors and empty responses instead of silently completing
• preserve Flash-Lite fallback by default while adding --no-gemini-fallback for fail-closed callers
• persist fallback behavior across stored and restarted sessions

Verification

• pnpm run lint
• pnpm test — 1,764 passed, 43 skipped
• pnpm run build
• scoped oxfmt --check for all changed implementation, test, and documentation files
• live Gemini web smoke tests completed successfully with Flash and Pro

Live Gemini web proof (redacted)

Run against reviewed head 0be49e51c3a6ae8f4aa694c77f5ba2e083d2e732, 2026-08-18, with a signed-in Chrome profile at gemini.google.com. Cookie values, headers, and local paths are redacted; request shape, model selection, and success signal are preserved.

1. Automated live smoke (ORACLE_LIVE_TEST=1 pnpm vitest run tests/live/gemini-web-live.test.ts -t "with Gemini 3\.5 Flash$|with Gemini 3\.1 Pro$"):

 RUN  v4.1.10 oracle

 ↓ Gemini web (cookie) live smoke > returns a short text answer with Gemini 3.1 Flash-Lite
 ✓ Gemini web (cookie) live smoke > returns a short text answer with Gemini 3.5 Flash 6765ms
 ✓ Gemini web (cookie) live smoke > returns a short text answer with Gemini 3.1 Pro 6771ms
 ↓ (4 unrelated smokes skipped: attachment upload, youtube mode, generate-image, edit-image)

 Test Files  1 passed (1)
      Tests  2 passed | 5 skipped (7)
   Duration  14.21s

2. CLI end-to-end run, Flash (oracle --engine browser --model gemini-3.5-flash --prompt "Say OK." --wait --verbose):

Using Gemini web client for browser automation
[verbose] Browser config: {"chromeProfile":"Default","desiredModel":"Gemini 3.5 Flash","modelStrategy":"current","debug":true,...}
Launching browser mode (picker=current; requested=gemini-3.5-flash) with ~10 tokens.
[gemini-web] Starting Gemini web executor (TypeScript)
[gemini-web] Loaded Gemini cookies from Chrome (node): 16 cookie(s).
[gemini-web] Completed in 2039ms
Answer:
OK.

2.0s · gemini-3.5-flash[browser] · ↑10 ↓1 ↻0 Δ11

3. CLI end-to-end run, Pro (oracle --engine browser --model gemini-3-pro --prompt "Say OK." --wait --verbose):

Using Gemini web client for browser automation
[verbose] Browser config: {"chromeProfile":"Default","desiredModel":"Gemini 3.1 Pro","modelStrategy":"current","debug":true,...}
Launching browser mode (picker=current; requested=gemini-3-pro) with ~10 tokens.
[gemini-web] Starting Gemini web executor (TypeScript)
[gemini-web] Loaded Gemini cookies from Chrome (node): 16 cookie(s).
[gemini-web] Completed in 5390ms
Answer:
OK.

5.4s · gemini-3-pro[browser] · ↑10 ↓1 ↻0 Δ11

Both runs used the updated StreamGenerate request path from this branch (current main's compact payload was not exercised — Chrome would need a branch switch to compare), and both attribute the response to the requested model in the final summary line.

Note: the [browser] Model selection evidence: ... verified=no field visible in raw logs is structural for Gemini web mode — it has no UI-picker verification step the way ChatGPT browser mode does, since it's a direct API call rather than clicking a picker. The actual evidence of correct model selection is the desiredModel in the request config plus the model[browser] tag on the final summary line, both shown above.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 30, 2026, 4:06 AM ET / 08:06 UTC.

ClawSweeper review

What this changes

This PR refreshes Oracle’s cookie-based Gemini web request format and model headers, adds clear response failures and an opt-out from Flash-Lite fallback, and persists that option across restarts.

Merge readiness

⚠️ Ready for maintainer review - 3 items remain

The central Gemini web repair is not on current main, and the supplied exact-head live evidence is sufficient for the Flash and Pro text paths. The PR has no definite introduced correctness finding, but GitHub reports it as dirty against current main, so it needs a clean rebase and refreshed merge review before landing.

Priority: P1
Reviewed head: 0be49e51c3a6ae8f4aa694c77f5ba2e083d2e732

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The implementation and exact-head Flash/Pro evidence are solid, with merge readiness held back by the dirty current-main integration.
Proof confidence	🐚 platinum hermit (4/6)	Sufficient (terminal): The changed production owner is the direct Gemini web request client; the PR body supplies exact-head, signed-in Chrome live-smoke and CLI traces showing successful Flash and Pro responses after the protocol update. Re-run those traces after rebase to prove the merge result, with private values kept redacted.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The changed production owner is the direct Gemini web request client; the PR body supplies exact-head, signed-in Chrome live-smoke and CLI traces showing successful Flash and Pro responses after the protocol update. Re-run those traces after rebase to prove the merge result, with private values kept redacted.
Evidence reviewed	6 items	Current main does not contain the protocol refresh: Current main still builds the prior compact request envelope and sends only the older model header, so the PR’s central request-format work remains distinct. Introduced request and fallback handling: The reviewed head builds the 97-field request, carries model selection and request ID headers, and rejects failed or empty responses after fallback processing. Real behavior proof: The PR body provides redacted, exact-head terminal traces from signed-in Gemini runs: live Flash and Pro smoke tests passed, followed by successful CLI answers for both models.
Findings	None	None.
Security	None	None.

How this fits together

Oracle’s browser engine can send signed-in, cookie-based requests directly to Gemini’s web service. CLI options and saved session settings configure the request builder, whose parsed response becomes the CLI answer or a clear error.

flowchart LR
  A[CLI options] --> B[Saved session settings]
  B --> C[Gemini request builder]
  C --> D[Gemini web service]
  D --> E[Response validation]
  E --> F[CLI answer or error]

Loading

Before merge

• Resolve merge risk (P1) - GitHub reports the head as dirty against current main, so the exact merged request behavior cannot yet be evaluated.
• Resolve merge risk (P1) - Gemini’s private web protocol is availability-sensitive; the supplied Flash and Pro proof is strong for the reviewed head but should be refreshed after conflict resolution.
• Complete next step (P2) - The PR head is dirty against current main, so a clean rebase and review refresh are required before its exact merge result can be assessed.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Implementation and test delta	implementation +108/-41, tests +133/-30, docs +7	The protocol refresh is materially covered by focused fallback, model-header, and upload request-shape tests.

Merge-risk options

Maintainer options:

1. Rebase and refresh Gemini proof (recommended)
   Resolve the dirty merge state, then rerun the focused signed-in Flash and Pro Gemini smoke paths on the rebased head before merge.
2. Pause the branch
   Keep the PR open until its current-main integration can be reviewed if the protocol capture or signed-in validation environment is no longer available.

Technical review

Best possible solution:

Rebase the protocol refresh cleanly onto current main, retain the default Flash-Lite fallback with the explicit opt-out, and rerun the focused Flash and Pro live Gemini checks on the rebased head.

Do we have a high-confidence way to reproduce the issue?

No: a high-confidence current-main failing run was not established. The supplied evidence demonstrates successful after-fix runs on the reviewed head, while current main retains the older request shape.

Is this the best way to solve the issue?

Unclear: the exact-head source and live traces support the approach, but the dirty merge state prevents confirming the final integrated request behavior.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against bbc1b3b0261d.

Labels

Label justifications:

• P1: A broken Gemini web request path prevents real browser-engine Gemini runs for affected users.
• merge-risk: 🚨 availability: This changes the private request protocol and response-failure handling used by Gemini browser runs.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The changed production owner is the direct Gemini web request client; the PR body supplies exact-head, signed-in Chrome live-smoke and CLI traces showing successful Flash and Pro responses after the protocol update. Re-run those traces after rebase to prove the merge result, with private values kept redacted.
• proof: sufficient: Contributor real behavior proof is sufficient. The changed production owner is the direct Gemini web request client; the PR body supplies exact-head, signed-in Chrome live-smoke and CLI traces showing successful Flash and Pro responses after the protocol update. Re-run those traces after rebase to prove the merge result, with private values kept redacted.

Evidence

What I checked:

• Current main does not contain the protocol refresh: Current main still builds the prior compact request envelope and sends only the older model header, so the PR’s central request-format work remains distinct. (src/gemini-web/client.ts:233, bbc1b3b0261d)
• Introduced request and fallback handling: The reviewed head builds the 97-field request, carries model selection and request ID headers, and rejects failed or empty responses after fallback processing. (src/gemini-web/client.ts:243, 0be49e51c3a6)
• Real behavior proof: The PR body provides redacted, exact-head terminal traces from signed-in Gemini runs: live Flash and Pro smoke tests passed, followed by successful CLI answers for both models. (0be49e51c3a6)
• Current merge state: GitHub reports the reviewed head as dirty against current main; no pinned test-merge result is available, so post-rebase behavior has not been assessed. (0be49e51c3a6)
• Feature history: Current-main blame ties the established Gemini model IDs and default/fallback constants to the original model-mapping work. (src/gemini-web/models.ts:10, 80dc4f7adbac)
• Release and main inclusion check: No local release tag contains the PR head, and current main does not contain it; the latest stated release is v0.17.3. (0be49e51c3a6)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Michal Kubenka: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Rebase onto current main and refresh the focused signed-in Flash and Pro proof against that rebased head.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (2 earlier review cycles)

• reviewed 2026-08-18T05:24:37.454Z sha 0be49e5 :: needs maintainer review before merge. :: none
• reviewed 2026-08-24T07:13:17.379Z sha 0be49e5 :: needs maintainer review before merge. :: none