fix(web): re-selecting the current model keeps its options#16572

Review in Change Stack →

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This bug fix changes model-selection behavior across chat and several persisted settings, including project product defaults that now retain model options when reselected. Human review is required for changes to product defaults.

^{You can add or adjust custom eligibility rules. Learn more.}

On the Macroscope verdict at 8899af6dc4: the change to how defaults are saved is intended, and it is narrow. In Settings › General the default model picker and the text generation picker still save on every pick. Picking a different model saves the same selection as before. Re-picking the model already selected now saves that selection with its traits, rather than a bare { instanceId, model }. A re-pick of an automatic default still pins it, and a re-pick in a mixed scope still unifies it. Nothing else about saving changes. The before and after screenshots are under "Settings › General › Model" in the description. This still needs a maintainer's review.

@coderabbitai Declining the nitpick from review 5562644129, which asks for browser coverage of the source control writer and review guide pickers at 89a82d6327. You are right that the current fixture does not exercise them. No browser test in apps/web drives a pick through ProviderModelPicker: the only one checks trigger labels. A test here would need provider snapshots, connected server targets, the scoped model availability hook and a usable default model, all mocked, before it could open the virtualized combobox and pick a row. That is a new harness, and it is out of proportion to a two-line change at each call site.

The rules underneath are covered. resolveModelPick has unit tests in packages/shared/src/model.test.ts: a re-pick gives null, and any other pick starts from the given options. The description's Verification section records a before/after check of each handler's pick expression for a re-pick, another model, a mixed scope and no stored selection. Only the re-pick result changed.

@f4llenz Thanks for the clarification. I withdraw the browser-coverage nitpick from review 5562644129.

I confirmed that the existing picker browser tests check trigger labels, not model picks. The resolveModelPick unit tests cover re-picks and other selections. Both dedicated-model handlers use pickDedicatedModel, which handles mixed scopes separately.

Given that coverage and your documented handler checks, a new browser interaction harness is not necessary for this PR.

You are interacting with an AI system.

@coderabbitai A correction to my earlier reply. As of 967f54da17, the source control writer and review guide pickers no longer special-case Mixed. Both save resolveModelPick(displayed, instanceId, model) ?? displayed, where displayed is the resolved selection the picker and TraitsPicker show (activeSelection or reviewGuideSelection). The default model and text generation pickers follow the same pattern. Under Mixed, a re-pick of the representative's model saves its displayed selection, traits included, to every scope. Picking any other model saves the bare model, as before. The pickDedicatedModel helper is gone, so please disregard the part of your learning that says mixed scopes are handled separately.

@coderabbitai review

@coderabbitai Declining the outside-diff finding from your review of 967f54da17 ("Persist a same-model re-pick as explicit", ChatView.tsx:7446-7455). The early return is the fix this PR makes, not an omission.

• A re-pick in the composer is a no-op by design. The description says so under Change, and mobile's ThreadComposer.tsx behaves the same way. After a re-pick, the composer state is exactly what it would be if the picker had never opened. Any later update that could replace an inherited selection would replace it in both cases. Picking the model already in use does not ask to pin it.
• The suggested fix has side effects. setStickyComposerModelSelection calls setStickyModelSelection, which writes this thread's selection into the sticky selection new chats start from (composerDraftStore.ts, "survives … new chats"). With the fix, confirming the current model would change the model and options of other threads. That is the kind of silent change this PR removes. Setting explicit: true would also alter a draft the user never changed.

A picker that chooses a different model still writes the draft, the explicit flag and the sticky selection, as before.

@f4llenz Thanks for the clarification. I withdraw “Persist a same-model re-pick as explicit.”

I confirmed that the early return in ChatView.tsx preserves the draft, explicit-choice flag, and sticky selection. Calling setStickyComposerModelSelection there would update shared sticky state used to initialize new chats. That would violate the intended no-op behavior.

Picking a different model still reaches the draft and sticky-selection writes. My finding incorrectly applied the settings pickers’ save-on-re-pick behavior to the composer.

You are interacting with an AI system.

@f4llenz Thanks for the correction. My earlier statement that mixed scopes are handled separately was incorrect.

The source control writer and review guide pickers use resolveModelPick(displayed, instanceId, model) ?? displayed. The default model and text generation pickers follow the same pattern.

• Under Mixed, re-picking the representative’s model saves the displayed selection, including its traits, to every scope.
• Picking a different model saves the bare model, as before.
• pickDedicatedModel is gone.

The supplied active learnings do not contain the incorrect mixed-scope claim.

You are interacting with an AI system.

@f4llenz Thanks for the correction. The supplied learning describes the earlier displayed expression. Your correction for e4a1ef0c77 specifies resolveModelPick(stored, instanceId, model) ?? stored.

The mixed-scope behavior does not use a separate branch:

• Re-picking the representative’s model saves its selection, including traits, to every scope.
• Picking another model saves the bare model, as before.

My earlier statement about separate mixed-scope handling was incorrect.

You are interacting with an AI system.

Taking over this one as maintainer for batch web-misc-03. I will preserve your commits, update against main, and verify that re-picking a model keeps its active traits. This will remain unmerged for the coordinator. Thanks for the focused fix.

thanks @f4llenz. your shared identity guard and settings handlers keep the fix focused. i retained your commits and tests, merged current main, and moved the composer guard into main's extracted useComposerSelection hook. the final diff is seven files, +67/-14. no unrelated changes were added.

same-model composer picks remain a state no-op apart from focus. all four settings pickers save their displayed selection with its traits, including the existing mixed-scope behavior. choosing another model or provider keeps the prior remembered/default behavior.

verification on 3f6b0acd7e9578fcc4c8074ad2301c08ec34affa:

• vp run check:changed passed through blacksmith: formatting, lint, both knip passes, typechecks for 29 affected packages, and 62 tests including the existing settings browser test.
• 154 focused model-selection, draft-store, and chat-logic tests passed. removing the identity guard makes the re-pick regression fail; restoring it passes.
• real isolated web app, system chrome: current main resets High to Medium on a GPT-6-Astra re-pick; this head keeps High. all four settings pickers retain High, including after reload. composer re-pick keeps High and leaves persisted composer state unchanged.
• all 31 CI checks are green on this head, including all eight server shards, web tests, build/typecheck, and the four Macroscope checks. two independent GPT-6.1-Sol reviews of this exact head found no issues.

unverified: mixed environments and unavailable-provider fallbacks in the live app, other provider catalogs, native desktop/mobile, remote/relay/tunnel clients, and provider turn dispatch. no provider turns or review guides were started. the shared guard is provider-independent; native mobile is unchanged.

git.cafe renders these external uploads as links. the image destinations loaded at 1440×1000, and both video destinations played through and supported seeking in chrome.

before, current main after re-picking GPT-6-Astra:

main resets high to medium

main re-pick recording

after, this head with matching starting selection and viewport:

updated head preserves high

updated head re-pick recording