feat(remote): dispatch Gemini browser models through the Gemini web executor

[solomonneas]

Problem

Oracle 0.18.0 supports Gemini browser runs through createGeminiWebExecutor, but that provider selection is local-only.

In bin/oracle-cli.ts, both the new-run and restart paths select the remote executor first:

if (browserConfig && remoteHost) {
  executeBrowser: createRemoteBrowserExecutor(...)
} else if (browserConfig && model.startsWith("gemini")) {
  executeBrowser: createGeminiWebExecutor(...)
}

The remote server then defaults /runs to runBrowserMode from browserMode.ts. The remote payload carries browserConfig.desiredModel, but the server does not use it to select the Gemini web executor.

I did not find an existing issue for remote Gemini. This report is based on source inspection at 083bba7e61f487ad3d99b42039d9f603f61dc4ff. A live local Gemini smoke reached the manual-login cookie extraction path, so the host-side authentication design works independently of this dispatch gap.

Expected behavior

A browser run with a Gemini model and --remote-host should execute the Gemini web provider on the remote host. Google cookies and browser state must remain on that host.

An unknown browser provider should fail before launching the ChatGPT executor. It should not silently substitute providers.

Suggested shape

Extract the local browser-provider selection into one shared resolver used by:

• new CLI browser runs
• restarted browser sessions
• MCP browser runs
• src/remote/server.ts

The existing browserConfig.desiredModel may be enough to preserve the current wire schema. An explicit provider field would make the contract easier to validate if model aliases can be ambiguous.

The remote server should keep its current credential policy: discard client-supplied inline cookies and use only host-side cookie or manual-login configuration.

Regression tests

• Remote ChatGPT model invokes runBrowserMode.
• Remote Gemini model invokes createGeminiWebExecutor.
• Client-supplied Gemini cookies are discarded.
• Unknown provider fails closed.
• Restart and MCP paths use the same resolver as a new CLI run.

I can prepare a PR after the preferred resolver and wire-contract shape are confirmed.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 24, 2026, 3:37 AM ET / 07:37 UTC.

Summary
Keep open for a maintainer product decision: current main still routes every remote browser request through the ChatGPT executor, while the documented remote service is ChatGPT-only. Adding Gemini support would extend the remote provider contract across host-side authentication, dispatch, and compatibility boundaries.

Reproducibility: yes. at source level: a remote Gemini request selects the remote client, whose server unconditionally invokes ChatGPT browser automation. A live remote Gemini host was not run during this read-only review.

Maintainer decision needed

Question	Recommendation
Should oracle serve remain explicitly ChatGPT-only, or should it support a provider-aware remote browser contract for Gemini?	Keep the service ChatGPT-only: Reject Gemini requests on the client before sending them remotely and document the remote browser service as ChatGPT-only.

Why: Current documentation and host setup are ChatGPT-specific, while the recent remote hardening treats provider-relevant configuration as a security-sensitive boundary; source alone cannot choose the supported contract or compatibility policy.

Next step
A maintainer must choose the remote provider contract before a bounded implementation can be safely specified.

Review details

Best possible solution:

Resolve the remote-service scope first; if Gemini is accepted, add a provider-aware, fail-closed protocol with host-owned Gemini setup, shared dispatch for new and restarted runs, focused remote tests, and updated operator documentation.

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

Yes at source level: a remote Gemini request selects the remote client, whose server unconditionally invokes ChatGPT browser automation. A live remote Gemini host was not run during this read-only review.

Is this the best way to solve the issue?

Unclear until service scope is chosen: extracting a resolver is maintainable, but it cannot by itself decide the remote provider protocol, host login lifecycle, or compatibility behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A provider extension must reject unknown providers before host browser I/O and continue to use only host-owned Gemini credentials and profiles.
• Inferring provider solely from desiredModel may create alias and upgrade ambiguity; the remote wire contract needs an explicit compatibility decision.

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

Label changes

Label justifications:

• P3: This is a useful but optional expansion of the documented ChatGPT-only remote browser service rather than a break in its existing contract.
• impact:auth-provider: The request changes remote provider routing and the host-side browser authentication model used for Gemini.

Evidence reviewed

What I checked:

• Current remote dispatch: The remote server imports and invokes the ChatGPT browser runner for every accepted request; it has no Gemini executor or provider-dispatch branch. (src/remote/server.ts:13, 79e483bd9dc8)
• Model selection is not preserved as provider dispatch: The CLI selects the remote executor before its local Gemini executor, so a Gemini request with a remote host reaches the server’s ChatGPT-only path; restart follows the same ordering. (bin/oracle-cli.ts:2275, 79e483bd9dc8)
• Documented remote-service boundary: The remote-service documentation directs the host operator to sign in to ChatGPT and describes host-side credential reuse, while the general browser documentation separately identifies Gemini as a cookie-based client. (docs/browser-mode.md:354, 79e483bd9dc8)
• Host authority policy: Remote clients may supply desiredModel, but the server rebuilds config from a conversation-only allowlist and explicitly discards client cookie data; provider support must preserve that host-owned boundary. (src/remote/server.ts:737, 79e483bd9dc8)
• Recent area provenance: The current conversation-only remote configuration boundary was introduced by the recent serve hardening, making its author a relevant routing candidate for any provider-contract change. (src/remote/server.ts:737, 954f13278b42)

Likely related people:

• Caleb Sowers: Authored the recent remote allowlist hardening that controls which client settings can reach the host browser. (role: introduced the current remote authority boundary; confidence: high; commits: 954f13278b42; files: src/remote/server.ts, tests/remote/server.test.ts)
• Peter Steinberger: Recent browser/remote configuration work and the release history connect this contributor to the service’s host-side browser policy. (role: recent browser and remote-policy contributor; confidence: medium; commits: 3a185f55918a, 6b17e6db0cae; files: src/remote/server.ts, bin/oracle-cli.ts, docs/browser-mode.md)

How this review workflow works

• 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.