Fable 5.1 not selectable for Remote Control sessions ("Update to use this model") although the account serves claude-fable-5-1; remote-control server never adopts CLI updates; desktop app sends short model ids the CLI rejects

> **Correction (2026-09-17, same day):** the first version of this issue attributed the problem to the `per_provider.gateway` alias mapping in the client bundle. That was wrong — `gateway` is the enterprise-gateway login provider (`CLAUDE_CODE_USE_GATEWAY`), not Remote Control. Retracted. What follows is what actually reproduces.

## Summary

Fable 5.1 (`claude-fable-5-1`) is served to this account by the API and by the CLI, but it **cannot be selected for a Remote Control session** from any client (Linux desktop 2.110.1, claude.ai/code, mobile). The picker shows **"Update to use this model"** even though every client and the CLI are the newest published builds. A local session can work around it by typing `/model claude-fable-5-1`; a Remote Control session cannot, because its model changes are routed through the server and never reach the CLI.

Three separate defects contribute, and the UI message points at none of them.

## Environment

- Ubuntu 24.04.4 LTS, x86_64
- Claude Desktop (Linux beta) 2.110.1 — bundles Claude Code 2.1.271
- Claude Code CLI 2.1.275 (`~/.local/bin/claude`)
- `claude remote-control --spawn=same-dir --capacity=5 --permission-mode default` run as a user systemd service
- Claude Max subscription, claudeai login (no gateway/Bedrock/Vertex)

## Finding 1 — a long-running `remote-control` server never adopts CLI updates

The server was started 2026-08-27 on 2.1.235. Every session it spawned afterwards ran `~/.local/share/claude/versions/2.1.235`, including one spawned 2026-09-16 06:48 — twenty minutes *after* 2.1.273 had been installed on the same machine. Sessions on that runtime reported `/model claude-fable-5-1` → **"Unsupported model"** and `/model fable` → served `claude-fable-5`, which is correct for a 2.1.235 catalog, but nothing in the UI says "the remote-control server is on an old build; restart it". `systemctl --user restart claude-remote-control` fixed this layer (spawned sessions now run 2.1.275).

Suggested: have the remote-control server notice a newer installed version and re-exec (or at least spawn new sessions from the current symlink target), and surface the spawning server's version in the session UI.

## Finding 2 — after the fix, the model still cannot be selected for a Remote Control session

With the session confirmed on 2.1.275:

- Desktop 2.110.1 picker, claude.ai/code picker, and the mobile app all refuse Fable 5.1 for the Remote Control session ("Update to use this model").
- The desktop web layer logs, at the moment of selection:
```
[REACT_QUERY_CLIENT] QueryClient error: {"name":"Error","message":"model is not selectable for this organization", ...}
```
- Nothing reaches the CLI: no transcript record, no server log line, and the CLI itself accepts the model:
```
$ claude -p "ok" --model claude-fable-5-1 --output-format json # modelUsage: claude-fable-5-1
$ claude -p "ok" --model fable --output-format json # modelUsage: claude-fable-5-1
```
- In a **local** desktop session, typing `/model claude-fable-5-1` goes app → CLI directly and succeeds (`LocalSessions.setModel: model=claude-fable-5-1`), so local sessions can use 5.1 while remote ones cannot — same account, same machine, same CLI.

So the gate is the server-side per-org/per-surface model selector config, not the client version. Whatever the entitlement state is, the message should say that ("not available for this account/surface yet"), not "update".

## Finding 3 — the desktop app sends short model ids the CLI rejects

The desktop app launches and re-targets sessions with short ids. From `main.log` for a local session:

```
[CCD CycleHealth] ... api_error: There's an issue with the selected model (fable-5-1). It may not exist or you may not have access to it.
LocalSessions.setModel: sessionId=..., model=fable-5
[CCD] setModel: CLI refused "fable-5" for ... while its recorded model "fable-5-1" is off the catalog; recording the pick for the next spawn
```

Reproducible from the CLI:

```
$ claude -p "ok" --model fable-5-1 # [claude-code:unrecognized_model] {"model":"fable-5-1","query_source":"sdk"}
$ claude -p "ok" --model fable-5 # unrecognized_model
$ claude -p "ok" --model opus-4-8 # unrecognized_model
$ claude -p "ok" --model claude-opus-4-8 # served
```

Either the app should send full ids / the alias (`fable`), or the CLI should accept the short spellings the app uses. Today the mismatch surfaces to users as an "unsupported model" they cannot fix.

## Steps to reproduce

1. Run `claude remote-control` as a persistent service; let the CLI auto-update underneath it. New Remote Control sessions keep the old version until the service is restarted (Finding 1).
2. Restart it. Open a Remote Control session from the desktop app or claude.ai/code and try to select Fable 5.1 → "Update to use this model"; web log shows `model is not selectable for this organization` (Finding 2).
3. Same machine, local session: `/model claude-fable-5-1` → works.
4. `claude -p "ok" --model fable-5-1` → `unrecognized_model` (Finding 3).

## Expected

- A Remote Control session on a current CLI should be able to use any model the account is served.
- When a model is gated by account/surface configuration, say so; do not tell the user to update when no update exists.
- The remote-control server should not keep spawning a stale binary indefinitely.

Start by inspecting the model registry and provider-routing entries in resources/app.asar, then compare the default and gateway mappings for fable, opus, and sonnet. Check the model picker, CLI model selection, and /status behavior described in the issue. Done means Remote Control reaches current models and no longer shows an update message when the limitation is route or rollout state.

Written by the indexing model from the issue text.