Linking the evidence from #16141 (closed as a dup of this one). It found a second race on the same path: OpenCode resolves mcp.add before the session's tool registry has the new server. The registry reloads on mcp.tools.changed through a 100 ms debounce, and flush only waits for the initial registration (packages/core/src/tool/mcp.ts, still the case in v2.1.0). So with #22944, a session.create or first prompt that follows mcp.add within ~100 ms could still miss the tools. It might be worth checking that case. Our local workaround holds the first prompt until the server's tools show up, and without it 5 of 5 first turns were empty on 2.0.22.
[Bug] OpenCode threads start with no T3 MCP tools on their first turn#22945
What happened
An OpenCode 2 thread's first model request sees an empty T3 tool catalog. The agent concludes delegation/orchestration is unavailable; the tools only appear when OpenCode refreshes the catalog on a later turn. Observed live: turn 1 contained zero t3-code-* tools in OpenCode's Code Mode catalog; turn 2 delivered them via a catalog-changed update.
Why
packages/provider-opencode/src/server/v2/adapter.ts adds T3's per-thread MCP server (t3-code-<threadId>) in prepareTurn, which runs after session.create in the first turn. OpenCode 2 builds a session's tool catalog at session creation, so the server misses the first request no matter how fast mcp.add completes.
A second, independent defect: the injected orchestration instructions advertise a flat tools.mcp__t3_code__* prefix, which matches no OpenCode Code Mode path (the real path is tools["t3-code-<threadId>"].<tool>), so even with tools present an agent following the instructions literally fails its first direct call.
Fix
https://github.com/pingdotgg/t3code/pull/22944 — registers the server in openSession before any session exists, and makes the instructions name the actual per-thread namespace. Per-thread isolation (distinct names + mcpRules deny/allow) is unchanged.