Model switch in RC/remote app doesn't propagate to local client until an RC-originated message is sent

Status Open
Reported on v2.1.218
Maintainer reply None cached
Activity 1 comment · opened Aug 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Summary

In a session driven from both the RC (remote/mobile companion) app and a local Claude Code CLI at the same time, switching the model in RC's picker does not update the session's active model until a message actually sent from RC arrives. A message typed directly in the local client always runs on whatever model was last set by an RC message — even if the user has since changed the RC picker and simply hasn't sent anything from RC yet. There is no warning that the local client is running on a stale model.

Evidence

Transcript entries carry a promptSource field distinguishing 'queued' (RC-originated) from 'typed' (local) messages, paired with the message.model of the response that followed:

queued (RC) messages -> model that followed:
promptSource=queued -> haiku (switch took effect)
promptSource=queued -> sonnet (switch took effect)
promptSource=queued -> opus (switch took effect)
promptSource=queued -> sonnet (switch took effect)

typed (local) messages -> model that followed:
~20 consecutive typed messages: model UNCHANGED from whatever was active before, in every case

Every queued message in the session correlated with a model change (matching a picker switch the user had just made on the phone). Every typed message, with zero exceptions across the whole session, left the model exactly as it was — never once picked up a pending phone-side switch.

Reproduction

  1. Start a Claude Code session accessible from both the RC/remote app and a local CLI.
  2. From RC, note the current model.
  3. Switch the model in RC's picker. Do not send a message from RC.
  4. Type an instruction directly in the local CLI.
  5. Observe: the local response runs on the model from step 2 (pre-switch), not the newly selected one — with no indication to the user that the switch hasn't taken effect.

Why this matters

A user can reasonably believe they've moved a shared session to a stronger/different model via the phone, then issue an important instruction from the local machine, and have it silently execute on the old model. There is no error, warning, or model confirmation surfaced to the local client indicating a pending unsent switch exists elsewhere.

Suggested fix

Either:

  • Make the model selection a session-level setting that updates immediately when changed in any connected client (regardless of whether that client sends a message), so all clients see the change right away; or
  • If the switch is inherently client-local until sent, surface a visible indicator in each client showing "model may be stale — a switch was made elsewhere and not yet sent" or similar.

What Should Happen?

Local machine should detect the model switch without waiting for message sent from rc.

Error Messages/Logs

Steps to Reproduce

  1. On a machine with Claude Code CLI installed, start a session in any project directory (local terminal).
  2. On a phone, open the RC (remote control) companion app and connect to that same session.
  3. From RC, send one message and confirm which model responds (e.g. ask "what model are you?").
  4. In RC, tap the model picker and select a different model. Do NOT send a message from RC after switching.
  5. Immediately switch to the local terminal and type an instruction directly (any message, e.g. "what model are you?").
  6. Observe: the local response still reports the OLD model from step 3, not the one selected in step 4 — with no warning, error, or indicator that a pending switch exists.
  7. To confirm precisely, inspect the session's transcript file directly (~/.claude/projects/<project>/<session-id>.jsonl). Each line has a message.model field showing which model served that response, and a promptSource field ('typed' for local input, 'queued' for RC-originated input). Filtering on this shows: every response to a 'queued' (RC) message reflects the just-selected model, while every response to a 'typed' (local) message keeps the model unchanged, regardless of any pending RC-side switch.

Minimal reproduction of the transcript check (Python), run against the session's own .jsonl file:

import json, glob, os
path = glob.glob(os.path.expanduser("~/.claude/projects//.jsonl"))[0] # replace with the actual session file
for line in open(path, encoding="utf-8"):
rec = json.loads(line)
msg = rec.get("message", {})
if msg.get("role") == "user":
print("USER", rec.get("promptSource"))
elif msg.get("model"):
print(" ->", msg["model"])

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.218 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗