t3_thread_launch accepts a model the provider instance does not advertise, creating a thread that fails immediately #26619

What happened

An agent in another T3 thread called the MCP tool t3_thread_launch with modelSelection: { instanceId: "claudeAgent", model: "gpt-6-astra" }. gpt-6-astra is a Codex model, not a Claude one. The server accepted the launch and created the thread. About two seconds later the run failed with the provider message "There's an issue with the selected model (gpt-6-astra). It may not exist or you may not have access to it." and the thread became failed.

Expected: the launch is rejected up front with a validation error saying claudeAgent does not offer gpt-6-astra, ideally listing the models it does offer, so the calling agent can fix its call instead of leaving a dead thread behind.

Diagnosis

t3_thread_launch never checks the requested model against the instance's advertised models.

• apps/server/src/mcp/toolkits/project/handlers.ts:180-233 (tag v0.1.4-nightly.20261028.3838) resolves modelSelection from the input, a replayed launch, the caller, or project defaults, then passes it straight to ThreadMessageIntake.launchThread. The only provider error it maps to invalid_request is ThreadManagementProviderInstanceDisabledError. Nothing compares model against the instance's model list.
• delegate_task already has this check: apps/server/src/mcp/OrchestratorMcpService.ts:1346-1355 fails with model_unavailable ("Model X is not advertised by provider Y.") when the instance advertises a non-empty list that does not contain the requested slug. t3_thread_launch does not reuse it.
• On this machine the claudeAgent provider status advertised 13 models (claude-opus-5-5, claude-sonnet-5-5, ... claude-haiku-4-5), none of them gpt-6-astra. codex advertises gpt-6-astra. So the server had what it needed to reject the call.
• The provider event log shows the selection reaching the Claude Agent SDK unchanged: query.open with "model":"gpt-6-astra", followed by a <synthetic> assistant error and a cancelled command.
• Still present on main (4 commits ahead of the tag): the handler's error mapping is unchanged and has no advertised-model check.

The same check is probably missing from other MCP paths that accept an explicit modelSelection (create_threads, t3_thread_configure, the latter tracked in #25723).

Steps to reproduce

1. Have a claudeAgent instance enabled (it advertises only Claude models).
2. From any MCP caller, call t3_thread_launch with a project and modelSelection: { instanceId: "claudeAgent", model: "gpt-6-astra" } (any slug that instance does not advertise), plus a message.
3. The call succeeds and returns a thread id and run id.
4. Within a few seconds the run fails with "There's an issue with the selected model (gpt-6-astra)..." and the thread is failed.

Expected at step 3: invalid_request / model_unavailable naming the instance and listing its advertised models, and no thread created.

Version

0.1.4-nightly.20261028.3838 (server, read from /.well-known/t3/environment). The t3 triage CLI was 0.1.3.

Environment

WSL2 Ubuntu (Linux 6.18 x64), Node v26.12.1, T3 server reached as a linked environment from the macOS desktop app. The launching agent ran on the Mac.

Evidence

# provider/events.mcp-launch-e1996628...319d3.log (trimmed)
[2026-10-28T18:54:07.810Z] {"provider":"claudeAgent","protocol":"claude-agent-sdk.query","event":{"direction":"outgoing","payload":{"type":"query.open","options":{"model":"gpt-6-astra",...}}}}
[2026-10-28T18:54:08.706Z] {"provider":"claudeAgent",...,"payload":{"type":"assistant","message":{...,"model":"<synthetic>",...}}}
[2026-10-28T18:54:08.723Z] {"provider":"claudeAgent",...,"payload":{"type":"command_lifecycle","state":"cancelled",...}}

# caches/claudeAgent.json advertised models
claude-opus-5-5 claude-sonnet-5-5 claude-fable-5-1 claude-fable-5 claude-opus-5 claude-opus-4-8 claude-opus-4-7 claude-opus-4-6 claude-opus-4-5 claude-sonnet-5 claude-sonnet-4-6 claude-haiku-5-5 claude-haiku-4-5

Related issues

#25723 (t3_thread_configure applies no advertised-model check): same missing check on a different tool; that one is about reconfiguring a delegated child, this one is about the initial launch. #15716 (closed, toggled-off models in delegate_task) is the origin of the delegate_task check. Not a duplicate of either.

Fix applied or workaround

None on the machine. Workaround: the calling agent should read orchestrator_capabilities first and pass a model that instance advertises (for gpt-6-astra, instanceId: "codex").

Filed by

Claude Code (claude-opus-5-5) via t3 triage