opencode harness: t3-code MCP server intermittently absent from Code Mode execute catalog mid-session #15736

Activity

1. juliusmarminge commented on Oct 4, 2026

   

   juliusmarminge

   on Oct 4, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the careful report, @Sunsilkk! The notice text and the flapping timeline were really useful for tracing this.

   What I found

   • Not a duplicate of [Bug]: Codex turn sees partial MCP tool catalog during server startup #13437. That one is a Codex first-turn startup race, where optional MCP servers get dropped while they're still starting. Here, the t3-code-<thread> server was already connected and working, then left OpenCode's Code Mode catalog on a later turn.
   • Where the notice comes from. OpenCode emits "The Code Mode tool catalog has changed" itself whenever the visible inventory changes. An empty search result for orchestrator_capabilities means the namespace really was unregistered. browser and opencode are OpenCode's own namespaces, so the execute runtime itself stayed up.
   • Also expected: T3_ACP_MCP_NODE being unset. It only covers the ACP terminal fallback.
   • How T3 registers the server. apps/server/src/orchestration-v2/Adapters/OpenCode2AdapterV2.ts registers it once per directory in prepareTurn. I found two paths that can remove it mid-session.
     1. Event-stream reconnect. A reconnect resets every thread's remembered MCP registration (state.mcp = undefined) without removing the live server. The next turn calls mcp.add again, and OpenCode's replaceServer disposes the existing client before the new one has tools. That drops the namespace until the reconnect finishes. If the add takes longer than the 5 s INVENTORY_TIMEOUT, it logs Could not add T3 Code's MCP server to OpenCode and leaves the registration unset, so the next turn tears the server down again. Repeated cycles would match the present, absent, present flapping you saw.
     2. Transport close. OpenCode clears a server's tools when its transport closes. It only reconnects when a session-expired response comes back, such as the 404 a restarted T3 process returns for an old in-memory session id. After any other close, the namespace stays gone, and T3 won't re-add it because it still thinks the server is registered.
   • Less likely: credential expiry. The token is refreshed on every provider turn.

   Likely fix area

   • Option 1: avoid replacing a live server. After an event-stream reconnect, check what OpenCode actually has registered instead of resetting and calling mcp.add again.

   • Option 2: re-register when the server disappears. Detect that the t3-code-* server is missing, for example by checking the inventory each turn, and register it again rather than trusting the remembered state.

   • Option 3: handle a slow add more gracefully. When the 5 s add timeout hits, avoid tearing the server down again on the following turn.

   • Logs that would tell the paths apart:

     • From T3, around a drop: Lost the OpenCode event stream; reconnecting. or Could not add T3 Code's MCP server to OpenCode.
     • From OpenCode, for the t3-code-* server: mcp session expired, reconnecting or Connection closed.

     If you can share those lines (redacted), please do.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 4, 2026