MCP token keeps the old provider after a thread switches back to a reused provider session; delegate_task fails with parent_not_active

What happened

Version: 0.0.46-nightly.20261005.2702 (Linux, systemd user service).

Thread runs on Claude (claude_proxy). Its Claude provider session stays alive.
The user switches the thread to Codex (codex_proxy, shared session). Codex attaches to the thread. prepareMcpSession(thread, codex_proxy) revokes the thread's credential and issues a Codex-scoped one into the per-thread slot.
The user switches back to Claude. The old Claude provider session is still in sessions and still attached to the thread, so ensureThreadAttached does not call prepareMcpSession. The Claude process starts (--resume) with the token from the slot. That token is still scoped to codex_proxy.
Every orchestration call that checks the live caller fails:
- delegate_task: parent_not_active: Delegated tasks require an active run owned by this MCP provider session.
- t3_queue_cancel: parent_not_active: The calling provider no longer owns an active thread run.
The active run is correct (providerInstanceId: claude_proxy, rootNodeId set). The mismatch is scope.thread.providerInstanceId (codex_proxy).

Evidence: orchestration_v2_projection_provider_session_bindings lists both provider-instance:claude_proxy:thread:<id>:… and provider-instance:codex_proxy:shared for the thread. The trace shows no McpSessionRegistry.issue when the thread went back to Claude.

Expected

When a run starts on a provider, the thread's MCP credential is scoped to that provider. If the slot holds a credential for another provider, it is rotated, even when the provider session is reused.

Workaround

Restart the T3 service. The next run opens a fresh Claude session, which issues a correct token.

Possible fix

On each run start (or provider process spawn), call prepareMcpSession(threadId, run.providerInstanceId), not only when the thread is newly attached. Or keep one slot per thread and provider, not one per thread.

Related: #15173 (also about session reuse and delegated runs).

fix(server): T3 tools work again after a thread switches back to a re…

Note

Grok responding on behalf of Julius.#18852 is the 401 form of this bug. After Claude → Codex → Claude → Codex inside Codex's 30-minute idle window, Codex keeps a revoked MCP credential and every T3 tool returns "Authentication required". PR #17096 lists this as a known limit. A complete fix needs per-(thread, provider instance) credentials, or releasing the previous provider's session on switch.

Prepared the focused sequential switch-back repair in #18884. It refreshes the reused native MCP client as well as the server credential, preserves peer conversations, and covers retained starts and interrupted issuance. Focused tests pass; the linked fork CI is running. Live provider-switch verification remains untested.

fix(server): switching providers no longer revokes the other provider…

fix(server): T3 tools keep working after a thread returns to a retain…

docs(internals): software factories ledger of pinned upstream depende…

fix(server): T3 tools keep working after a thread returns to a retain…

docs(internals): software factories ledger of pinned upstream depende…

A fresh fix from current main is in #35331. It replaces #19413, which was closed as stale with a request to open a new PR from main. The regression test there fails on main at 2482b03 (after an A → B → A switch, the first provider's token no longer resolves) and passes with the fix.

I already have more open PRs than the open PR limit allows, so the limit check may close #35331 on arrival. If you'd like it reviewed, a maintainer can reopen it, add triage:keep-open so I can reopen it, or add me to the PR limit exemptions.

🤖 Generated with Claude Code

This is the same problem as #23198, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.

@Alb11747

I tested whether #23198 fixes this, because I believe it does not.

#23198 releases the previous provider session when a thread sends to another provider instance (#20343). The problem here is the MCP token store, which McpProviderSessions keys by thread only. After a thread goes A → B → A, the store holds B's entry for that thread, and the first provider's token no longer resolves.

I ran the regression test "preserves MCP access through A → B → A and isolates cleanup" from #35331 (by @Alb11747) in a throwaway worktree on main at fc2b5de, which contains #23198's merge c0ec87a (git merge-base --is-ancestor exits 0):

Test alone, in ProviderSessionManager.test.ts: fails, 1 of 66 (expected undefined to equal 'thread-provider-session-manager-switc…').
Same file with the production change from fix(server): switching providers no longer revokes the other provider's T3 tool access #35331 (head 00a0135) applied: passes, 66 of 66.

The test and the fix are theirs; I only ran them.

fix(server): T3 tools keep working after a thread returns to a retain…

docs(internals): software factories ledger of pinned upstream depende…

This still happens on current main (eb14ddb, which includes #23198). Repro and details are in #36453.

Posted by Claude Opus 5.5 on behalf of Alb11747.

fix(server): T3 tools keep working after a thread returns to a retain…

docs(internals): software factories ledger of pinned upstream depende…

fix(server): T3 tools keep working after a thread returns to a retain…

docs(internals): software factories ledger of pinned upstream depende…

Navigation Menu

Repository navigation

MCP token keeps the old provider after a thread switches back to a reused provider session; delegate_task fails with parent_not_active #16565

What happened

Expected

Workaround

Possible fix

60 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

MCP token keeps the old provider after a thread switches back to a reused provider session; delegate_task fails with parent_not_active #16565

Description

What happened

Expected

Workaround

Possible fix

Activity

juliusmarminge commented on Oct 12, 2026

Alb11747 commented on Oct 13, 2026

60 remaining items

Alb11747 commented on Nov 12, 2026

juliusmarminge commented on Nov 12, 2026

bompus commented on Nov 12, 2026

Alb11747 commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions