[Bug]: t3_thread_configure moves a delegated child onto a model that delegate_task refuses #25723

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Configure a Claude provider instance (for example proxy, pointed at a CLIProxyAPI hub) whose backend serves a model X that the instance does not advertise.
2. From an orchestrator thread, call delegate_task with target: { providerInstanceId: "proxy", model: "X" }. It fails with model_unavailable: Model X is not advertised by provider proxy.
3. Call delegate_task again with an advertised model (for example claude-opus-5-5). A child thread starts.
4. Call t3_thread_configure on that child's thread id with modelSelection: { instanceId: "proxy", model: "X" }. It returns { sequence }.
5. Cancel the child's run and send it a new message. The new run executes on X.

Expected behavior

Through MCP, t3_thread_configure refuses to move a delegated child to a model that delegate_task would refuse. To use another model, the caller starts a separate agent with delegate_task and an advertised model.

Actual behavior

t3_thread_configure applies no advertised-model check to a delegated child. delegate_task refuses an explicitly requested model when the instance advertises a non-empty model list that does not contain it (apps/server/src/mcp/OrchestratorMcpService.ts:1424-1433). The configure handler forwards the selection to dispatch without that check (apps/server/src/mcp/toolkits/thread/handlers.ts:188-203 on becf853def). Only the provider-switch checks in apps/server/src/orchestration-v2/ProviderSwitchService.ts:105-167 still apply.

An orchestrator agent used this as a workaround after delegate_task refused the model. Two children titled "(Opus)" then ran for about 13 hours on GPT models inside the Claude Code harness. The harness kept a 1M-token window assumption and planned compaction at 980K tokens. The swapped models reject input at about 921K tokens. So the children never compacted, and both failed with API Error: 400 Your input exceeds the context window of this model. That failure happens in the harness and the proxy, not in T3 Code. T3 Code's part is that the swap was possible at all, and that the thread title still named the old model.

Impact

Minor bug or occasional failure

Version or commit

Desktop 0.1.3-nightly.20261026.3740. The configure handler is unchanged on main at becf853def.

Environment

Windows 11, desktop app. Claude Code 2.1.311 through a Claude provider instance pointed at CLIProxyAPI v8.0.43. The orchestrator and the children were Claude Code sessions.

Logs or stack traces

delegate_task  -> {"_tag":"OrchestratorMcpFailure","code":"model_unavailable","message":"Model gpt-6-astra is not advertised by provider proxy."}
t3_thread_configure (child thread, model gpt-6-astra) -> {"sequence":2552399}
child transcript: 21 requests on claude-opus-5-5, then 450 requests on gpt-6-astra
child final turn: API Error: 400 Your input exceeds the context window of this model. Please adjust your input and try again.

Workaround

Do not reconfigure a delegated child. Cancel it, add the model to the provider instance's model list if it is missing, and start a separate delegate_task with that advertised model.

Possible fix

A focused fix is on a fork branch: mikeohuo/t3code@fix/configure-unadvertised-model. It moves the advertised-model rule from delegate_task into one helper, assertModelAdvertised, and t3_thread_configure calls it when the provider or model changes. An options-only change on the current model, an instance with no advertised models, and an unknown instance behave as before. No tool description or orchestration text changes. A new test in apps/server/src/mcp/toolkits/core.test.ts fails without the check and passes with it.

t3_thread_launch has the same gap: it forwards modelSelection with only the instance-enabled check (apps/server/src/mcp/toolkits/project/handlers.ts). It is not part of this fix.

Related: #22577 (a queued completion reverts a model change) and #24294 (conditional t3_thread_configure). Both concern configuring a long-lived orchestrator thread, which this change leaves alone.

Written with Claude Code (Opus 5.5). The investigation and the patch were done with Claude Code (Fable 5.1), including the red and green test runs. GPT-6 Astra checked the code claims independently and reran the tests. Kimi K3.1 Pro, Opus 5.5 and Fable 5.1 then reviewed the fix adversarially against CONTRIBUTING.md, and the narrow fix above follows their findings.