[Bug]: t3-code MCP credential expires when a turn waits on the user for more than 24 hours #14076

Activity

1. juliusmarminge commented on Sep 28, 2026

   

   juliusmarminge

   on Sep 28, 2026

   Member

   More actions

   Triage

   Confirmed on main at d15210cd3d (same commit cited in the report). The diagnosis matches the code.

   The bearer is minted once in prepareMcpSession when the provider session starts (ProviderService.startSession, and session recovery only when no live process is adopted). It is not rotated on later turns. touchActiveMcpThread runs only from sendTurn and compactThread. respondToUserInput and respondToRequest do not touch it, and nothing refreshes liveness while a turn is blocked.

   pruneDead runs before the refresh in resolve, issue, and touch. After DEFAULT_LIVENESS_WINDOW_MS (24h) with no MCP traffic and no new sendTurn/compactThread, the record is gone. A later answer cannot bring that bearer back, and the provider process keeps presenting it, which is why /mcp reconnect does not help. The 401 is invalid_mcp_credential; the server warning is rejected MCP request with an unusable credential with reason unknown_or_expired_token.

   This is the same gap #4659 left open. That change refreshes liveness at the start of each turn, so idle time between turns is covered. A single turn that sits on a user question or an approval for more than 24 hours is not. The same thing happens for any in-progress turn that goes 24 hours without a t3-code call. The comment on DEFAULT_LIVENESS_WINDOW_MS says the window only bounds sessions that died without stopSession/stopAll. The implementation never checks that the session is still running.

   Touching on the answer is not enough for this report: the answer arrived at 44 hours, after the prune. Liveness has to be kept during the wait. The 24h bound should stay, because /mcp is outside environment auth and this bearer is the only guard. A still-running session (in a turn, or blocked on user input or approval) should count as alive; a session that exits uncleanly should still expire. The existing registry test only covers touches that land inside the window.

   The restart workaround holds: recovery adopts a still-running process without issuing a new credential, so the next message only gets a fresh bearer after the provider process is gone. Stopping that session and sending a new message does the same thing without restarting the whole server. Sending another message while that process is still up does not.
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 Sep 28, 2026
3. robertnisipeanu

   added 2 commits that reference this issue on Sep 28, 2026

   fix(server): keep MCP credentials alive while provider sessions run

   ...

   This issue will close once commit 4ba7ba2 is merged into the 'main' branch.

   4ba7ba2

   fix(server): keep MCP credentials alive while provider sessions run

   ...

   This issue will close once commit 9eaf08d is merged into the 'main' branch.

   9eaf08d