A move never replays the Agent SDK's mcp_set_servers request, so a relaunched T3 Code child has no t3-code MCP server #447

Failure

After an account move, the relaunched child of a T3 Code stream-json session has no t3-code MCP server: ToolSearch and claude mcp list show only the servers from settings, so delegate_task and every other T3 tool are gone until T3 Code stops and relaunches the session itself.

Evidence

Versions: tokenmaxxing 1.176.0, T3 Code 0.1.0 (Agent SDK bundled in its binary), Claude Code as installed on 2026-10-16.

• tokenmaxxing.log, session 03530e22: T3 Code's own four launches (--session-id, then --resume) and the supervisor's two moves (respawns=1) all carry the same 33 argument tokens, with no --mcp-config flag. The child's environment has no T3_CODE_MCP_AUTHORIZATION or other MCP variable. The T3-started children have the t3-code server; both moved children do not.
• The T3 Code 0.1.0 binary calls the Agent SDK's queryRuntime.setMcpServers(mcpServers) after the query starts, and the SDK sends it as the stdin control request mcp_set_servers. That request, not argv, carries the server's URL and bearer.
• src/entries/supervisor.ts:421: REPLAYED_REQUESTS holds initialize, set_max_thinking_tokens, set_model, and set_permission_mode. StdinRelay.forward keeps only those for the life of the session and attach replays them to each new child. mcp_set_servers is forwarded once to the first child; on a --resume move the relaunched child never receives it, and on the --session-id replay path it gets the moved-request error instead.
• Within two minutes on 2026-10-16 the log shows fifteen respawns=1 launches; the T3 Code Captain reported seven of those threads without the t3-code server and relaunched each from T3 Code by hand, for several of them the second or third time that day.

Why this is wrong

A T3 Code thread loses its orchestration tools on every move, and its end gate, reviews, and PR linking all stop until a person notices. The relay already replays the SDK's other setup requests for exactly this reason (#322, #330); the runtime MCP request is the one setup request it still drops.

Similar issues

• A move that resumes a stream-json session never sends the Agent SDK's initialize request to the relaunched child #322 and fix: send the Agent SDK's initialize request to every relaunched stream-json child #330: replay initialize, set_model, set_permission_mode, and set_max_thinking_tokens to every relaunched child. Same mechanism, different request.
• fix: replay a stream-json session's lost lines on a move before its first transcript row #324: replay the killed child's lines on a move before the first transcript row.

Not claimed

• Whether Claude Code answers a replayed mcp_set_servers before or after the resume prompt starts its first turn was not observed on a live move; a hermetic stub run will show the order the child receives.
• Whether T3 Code sends other runtime MCP requests (mcp_toggle, set_mcp_permission_mode_override) that a move should also replay was not checked.