[BUG] Remote Control (standalone bridge, Windows): model selected from phone or claude.ai never takes effect — session stays on host default

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On a Windows host running the standalone Remote Control bridge (claude remote-control --spawn worktree, supervised by PM2), the model chosen for a Remote Control session does not take effect. The session runs on the host's configured default ("model": "opus" in ~/.claude/settings.json) regardless of what is picked in the client, and picking a different model mid-session does not change the running model either.

This reproduces from both clients against the same bridge:

• the Claude mobile app (iOS), and
• the Code tab on claude.ai in a desktop browser.

The failure is silent — the client UI shows the newly selected model as active, so there is no indication the session is still on the host default until the running model is asked what it is, or until its behavior gives it away.

Practical effect: every Remote Control session on this host is pinned to the host default model. Deliberately selecting a cheaper or a more capable model for a session is not possible from either remote client.

This appears to be the same defect as #75272 (model picked at session start reverts to host default within seconds, standalone bridge, macOS) and #66666 (model selection in the app does not propagate to a --remote-control session; auto-closed as stale, not fixed), and the same class as #65373 (picker taps produce a checkmark but do not change the running model; auto-closed as stale after three independent confirmations). Filing fresh per the stale-bot's instruction, adding a Windows host and the claude.ai web client as a second affected surface.

Related but filed separately: effort/thinking level also does not follow the selection in Remote Control on this host. That is already covered by #79363 and is not part of this report.

What Should Happen?

The model selected in the Remote Control client should be the model the spawned session actually runs, and a mid-session change should take effect on the next turn — matching /model semantics in the terminal.

Failing that, the client should not display the unselected model as active. A picker that confirms a change it did not make is worse than a read-only picker.

Error Messages/Logs

No error is emitted. The bridge daemon logs show a normal session spawn; nothing indicates a rejected or ignored model parameter.

Host configuration (~/.claude/settings.json):

{
  "model": "opus",
  "effortLevel": "max",
  "remoteControlAtStartup": true
}

Bridge launch (one PM2 entry per repo, this is the affected one):

claude.exe remote-control --name "work" --spawn worktree
cwd: C:\Users\rdudl\Documents\Work

Steps to Reproduce

1. On a Windows host, set "model": "opus" in ~/.claude/settings.json.
2. Start the standalone bridge: claude remote-control --name "work" --spawn worktree (here: under PM2, autorestart: true).
3. From the Claude mobile app or the Code tab on claude.ai, spawn a new session against that bridge and select a non-default model (e.g. Fable 5) before or shortly after the first message.
4. Ask the session which model it is running.
5. It reports the host default (Opus), not the selected model. The client UI continues to show the selected model.
6. Open the picker mid-session and select a different model. Ask again — the running model is unchanged.

Claude Model

Opus (host default; the selected model never takes effect)

Is this a regression?

I don't know. It has been the behavior for as long as this host has used the bridge.

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Claude subscription (Max), not API key

Operating System

Windows 11 Pro 10.0.26200

Terminal/Shell

Bridge runs headless under PM2 (windowsHide: true); clients are the iOS app and claude.ai in a desktop browser.

Additional Information

The --spawn worktree mode spawns a child claude process per session. #75272 hypothesizes the model chosen in the client is not passed through to that child, which then falls back to the host's configured default. The behavior here is consistent with that: the running model is always exactly the value of model in the host's settings.json.

One partial workaround reported in #75272 — re-selecting the model after the session is running — does not hold on this host; the running model stays on the host default.