Browser mode's default model now silently switches accounts off their selected newer model (gpt-5.5-pro default × 0.17.2 picker navigation)

[postoso]

Setup

oracle 0.17.3 (brew tap), macOS arm64, browser lane with a persistent --browser-manual-login profile whose ChatGPT account has GPT-5.6 Sol selected with Pro effort.

What changed

Pre-0.17.2, a no--m browser run effectively rode the account's selected model (our runs resolved to GPT-5.6 Pro even though the requested alias was the gpt-5.5-pro default). Since 0.17.2's unified-picker navigation, the default alias actively selects the GPT-5.5 row — which is now a real, distinct model row in ChatGPT's Advanced → Model menu, not a stale label:

Model selection evidence: requestedKey=gpt-5.5-pro; target=GPT-5.5; resolvedLabel=GPT-5.5;
status=switched; strategy=select; verified=yes; source=chatgpt-model-picker

The run genuinely executes on GPT-5.5 Pro (ChatGPT's own "Used GPT-5.5 Pro" footer confirms). verified=yes faithfully verifies the switch — the switch itself is the surprise.

Why it bites

Every account sitting on a newer model gets silently downgraded on every no--m browser run. It hit us twice in one evening, including a consequential adjudication run we only caught via the ChatGPT footer afterward. The alias is doing exactly what its name says — the problem is that it's the default in a world where the account selection is newer.

Suggested fixes (any of these would resolve it)

1. Bump the browser default to the GPT-5.6 family — our preference: it's the current model and noticeably more thorough. (The GPT-5.5 Pro/GPT-5.5 branding in --help is stale throughout anyway.)
2. Make the no--m browser path default to current-model semantics (keep the account's selected model, apply only the effort control) — the pre-0.17.2 effective behavior.
3. At minimum, warn loudly when a switch away from the account's currently-selected model is caused by the default rather than an explicitly requested -m.

Workaround we've adopted meanwhile: always pass -m gpt-5.6-sol --browser-thinking-time pro (the new fail-closed pro level is great, by the way).

Happy to PR whichever direction you prefer.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 22, 2026, 5:21 AM ET / 09:21 UTC.

Summary
This issue remains necessary: current v0.18.0 still treats an omitted model as the explicit GPT-5.5 Pro default and selects it in ChatGPT. The generic Pro aliases now target GPT-5.6 Sol, but choosing omission semantics is a product-policy decision. Likely related people: steipete (high confidence) and dragonfsky (medium confidence).

Reproducibility: yes. from current source: omission resolves to gpt-5.5-pro, maps to GPT-5.5, and the default select strategy drives the picker. A signed-in live run would additionally confirm the account-specific UI result.

Root-cause cluster
Relationship: canonical
Canonical: #375
Summary: This is the remaining canonical question about omitted browser-model behavior; the related alias fix addressed explicit generic aliases only.

Members:

• partial_overlap: Browser: gpt-5-pro still targets GPT-5.5 instead of GPT-5.6 Sol + Pro #373 - Its resolved generic-Pro alias routing was addressed by commit 39b0d41, but this issue concerns the separate no-model default.
• adjacent_distinct: Browser: add first-class GPT-5.6 Sol model aliases #305 - It introduced explicit GPT-5.6 browser aliases, not the policy for an omitted model.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Maintainer decision needed

Question	Recommendation
Should a browser run with no CLI or configured model preserve the active ChatGPT model, or should it select the current generic Pro target instead of the legacy GPT-5.5 Pro default?	Use current generic Pro for browser omission: Resolve only a genuinely omitted browser model through the generic Pro alias, retaining explicit GPT-5.5 selections and leaving API defaults unchanged.

Why: Both options deliberately change established default-selection behavior and have different reproducibility, effort, cost, and API-compatibility consequences.

Next step
A maintainer must choose the default browser-model policy before a safe bounded change can be defined.

Review details

Best possible solution:

Choose a browser omission policy, then implement it narrowly so only truly omitted browser models use the chosen current-model or generic-Pro behavior while explicit CLI and config selections remain stable.

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

Yes, from current source: omission resolves to gpt-5.5-pro, maps to GPT-5.5, and the default select strategy drives the picker. A signed-in live run would additionally confirm the account-specific UI result.

Is this the best way to solve the issue?

No single implementation is best until maintainers choose omission semantics; changing only generic aliases does not affect the retained explicit default.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Changing the global default could alter API routing, cost, and session expectations; a browser-only omission policy must preserve explicitly configured or requested GPT-5.5 pins.

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

Label changes

Label justifications:

• P2: The default browser route can select a different model for ordinary signed-in users, but an explicit model or current strategy provides a workaround.
• impact:auth-provider: The requested change concerns ChatGPT account model routing and browser-side selection behavior.

Evidence reviewed

What I checked:

• Omitted-model resolution: The global default remains gpt-5.5-pro, and browser resolution uses that default when neither CLI nor user config supplies a model. (src/oracle/config.ts:10, 083bba7e61f4)
• Current browser behavior: The explicit gpt-5.5-pro label maps to GPT-5.5, while the default select strategy invokes model selection before prompt submission. (src/cli/browserConfig.ts:38, 083bba7e61f4)
• Regression coverage documents the distinction: Current tests assert that the legacy explicit GPT-5.5 Pro alias targets GPT-5.5, whereas generic Pro aliases target GPT-5.6 Sol with Pro effort. (tests/cli/browserConfig.test.ts:86, 083bba7e61f4)
• Supported opt-in behavior: Documentation says select is the default strategy and current preserves the active model; it also documents generic Pro aliases as GPT-5.6 Sol and gpt-5.5-pro as an explicit historical pin. (docs/browser-mode.md:106, 083bba7e61f4)
• Related fix provenance: Commit 39b0d41 changed generic Pro aliases to GPT-5.6 Sol while explicitly preserving the gpt-5.5-pro target, so it addresses the related explicit-alias report but not this omitted-model policy. (src/cli/browserConfig.ts:124, 39b0d416a937)
• Current-release check: The inspected main revision is tagged v0.18.0; it still contains the default and selection behavior above. (src/oracle/config.ts:10, 083bba7e61f4)

Likely related people:

• steipete: Authored the current generic-Pro routing fix and the default-model lines retained on current main. (role: recent browser-routing contributor; confidence: high; commits: 39b0d416a937, 6b17e6db0cae; files: src/cli/browserConfig.ts, src/oracle/config.ts, src/cli/runOptions.ts)
• dragonfsky: Introduced the GPT-5.6 Sol browser alias surface adjacent to the requested default behavior. (role: GPT-5.6 browser-alias contributor; confidence: medium; commits: f2f4a6c35605; files: src/cli/browserConfig.ts, tests/cli/browserConfig.test.ts)

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.