Phantom "Context handoff pending" when the composer's sticky selection points at a disabled provider instance #19956

What happened

I moved from the built-in Claude instance to a custom instance (claude_proxy, driver claudeAgent, its own homePath) and disabled the built-in one. After that, every thread on the desktop app showed "Context handoff pending · Claude Opus 5.5 → Claude Opus 5.5" below the last turn. All turns still ran on claude_proxy, so no handoff was ever going to happen. The banner was just always there.

Picking Claude (proxy) explicitly in the model picker once cleared it, and new threads stay clear after that.

Diagnosis

The composer and the handoff banner resolve the selected provider instance in different ways:

• The composer, picker and send path use resolveComposerProviderSelection (apps/web/src/components/ChatView.logic.ts:570). It only accepts a candidate instance that is entry.enabled && entry.isAvailable (line 603). A draft selection pointing at the disabled claudeAgent is skipped, and the thread's instance (claude_proxy) wins. Turns run on claude_proxy.
• The banner uses resolvePendingHandoff (packages/client-runtime/src/handoff.ts:23). It gets the raw draft selection: composerSelectedModelSelection ?? activeThread?.modelSelection (apps/web/src/components/ChatView.tsx:7566, from draft.modelSelectionByProvider[draft.activeProvider] at line 1914). It compares that with the latest run's modelSelection and doesn't check whether the target instance is enabled, or whether the user picked the selection rather than having it seeded. from.instanceId (claude_proxy) ≠ selection.instanceId (claudeAgent), and the two instances don't share a continuation group, so needsHandoff is true.

The stale draft selection comes from the composer's persisted sticky state (stickyModelSelectionByProvider / stickyActiveProvider in apps/web/src/composerDraftStore.ts, applied by applyStickyState). It still pointed at claudeAgent from before the switch, so every new thread's draft was seeded with it. Picking the proxy instance explicitly overwrote the sticky state, which matches the workaround.

Mobile probably has the same bug: apps/mobile/src/state/use-thread-composer-state.ts:340 also calls resolvePendingHandoff. I haven't checked mobile's input selection.

Possible fix: pass resolvePendingHandoff the resolved composer selection (the instance from resolveComposerProviderSelection) rather than the raw draft, or have it ignore targets that aren't enabled and available. It would also make sense to drop or re-seed sticky selections that point at a disabled instance.

Steps to reproduce

1. With the built-in Claude instance enabled, send a message in any thread from the desktop or web client so the composer's sticky selection is claudeAgent.
2. In Settings → Providers, add a custom Claude instance (e.g. claude_proxy, driver claudeAgent, separate CLAUDE_CONFIG_DIR). Make it the default, then disable the built-in Claude instance.
3. Start a new thread. The picker shows the custom instance. Send a message. The turn runs on the custom instance.
4. After the turn finishes, "Context handoff pending · Claude Opus 5.5 → Claude Opus 5.5" appears and stays, including on later threads.
5. Explicitly pick the custom instance in the model picker. The banner disappears, and new threads no longer show it.

Version

0.0.46-nightly.20261015.3158 (server and desktop). The code paths above are unchanged on main @ 42da166.

Environment

Server: Linux, headless t3 serve, reached over Tailscale. Client: T3 Code (Nightly) desktop on Windows. Instances: claude_proxy (driver claudeAgent, Claude Code 2.1.300) and codex_proxy (driver codex, codex-cli 0.162.1), with built-in claudeAgent and codex disabled.

Evidence

# Thread whose desktop view showed the banner (server statev2.sqlite)
orchestration_v2_projection_threads.provider_instance_id   = claude_proxy
  payload.modelSelection                                   = {"instanceId":"claude_proxy","model":"claude-opus-5-5"}
orchestration_v2_projection_runs (ordinal 1..3)            = claude_proxy, modelSelection.instanceId = claude_proxy
orchestration_v2_projection_provider_sessions              = claude_proxy (driver claudeAgent), status ready
orchestration_v2_projection_context_handoffs (this thread) = 0 rows
MCP t3_thread_transfers                                    = {"transfers": []}

# settings.json
"defaultModelSelection": { "instanceId": "claude_proxy", "model": "claude-opus-5-5" }
"claudeAgent": { "driver": "claudeAgent", "enabled": false }

# Manual check on the desktop client
1. Explicitly select "Claude (proxy)" in this thread's picker -> banner disappears
2. Start a new thread                                          -> no banner

Related issues

#15476: a real handoff between two instances of one provider shows "Claude Opus 5.5 → Claude Opus 5.5" because the endpoints lack the instance badge. That's why this phantom banner looks like a no-op, but the cause is different (rendering vs. selection resolution). #17506: hard to tell which provider instance is active in the composer. Related UX, not the same bug.

Fix applied or workaround

Explicitly select the intended instance in the model picker once. This overwrites the sticky selection. Nothing was changed on the server.

Filed by

claude (claude-opus-5-5) in a T3 Code thread, not via t3 triage. The diagnosis was checked against server state and main @ 42da166, and the workaround was confirmed manually by the user.