[Alb11747]

Problem

A thread holds only one T3 tool (MCP) credential. Opening a second provider instance on the same thread revokes that credential and replaces it. The first provider's process keeps the old token. When the thread switches back (A → B → A), that provider's T3 tool calls fail with 401 Authentication required or read a token scoped to the other instance (parent_not_active).

Change

Credentials are kept per thread and provider instance:

• McpProviderSessions stores one config per thread and provider instance. read takes the instance id, and clear can remove a single credential.
• Every adapter that reads the credential passes its own instance id: Claude, Codex, ACP, Cursor, Muse, OpenCode (v1 and v2) and Pi. Codex now reads every call site through its existing readMcpSession helper, including the hasPendingWake read added since fix(server): switching providers no longer revokes the other provider's T3 tool access #19413.
• ProviderSessionManager revokes only the credential it is replacing. On release, it defers revocation only to other live sessions of the same instance. Archive and delete still revoke every credential on the thread.
• Kept html_render references are dropped only when the thread's last credential goes. Otherwise, releasing one instance would discard pages that another instance had not yet consumed.

Scope

This is a fresh PR from current main that replaces #19413, as the closing comment asked. It starts from @juliusmarminge's maintainer takeover of #19413 at a569956, which preserved the original fix. It adds three things on top: the Codex read site that landed on main since then, a regression test that switches providers the way the orchestrator does, and the html_render cleanup fix from review.

Fixes #16565. Refs #18852.

Verification

The regression test is ProviderSessionManagerV2 preserves MCP access through A → B → A and isolates cleanup in apps/server/src/orchestration-v2/ProviderSessionManager.test.ts. It follows the orchestrator's real switch flow:

1. Open instance A, then detach it with "Provider or model selection changed."
2. Open instance B, then detach it the same way.
3. Reopen A.

It checks that both instances' tokens still resolve to the thread, that A gets back its original credential on the existing runtime, and that closing B revokes only B's credential and keeps a render that A recorded. Reopening B issues a fresh token.

• Base (main at 2482b03, with only the test file applied): vp test run src/orchestration-v2/ProviderSessionManager.test.ts gives 1 failed, 65 passed. The new test fails at the first access check after B opens. A's token resolves to undefined because opening B revoked it. This is the failure bompus reported when the automated capture missed it.
• Head: 66 passed.
• html_render cleanup: with only that change reverted, the test fails on the kept-render assertion.
• vp run check:changed: format, lint, knip, typecheck (27 packages) and tests beside the change (8 files, 880 tests) all pass.

What I could not check: authenticated Claude/Codex turns that switch providers in the UI were not run live. The test drives the session manager and credential registry with fake adapters. There is no UI change.

Implementation and integration: Claude Opus 5.5 in Claude Code, through T3 Code. Rebase draft: GPT-6.1 Sol. Review: Claude Opus 5.5 (fresh-context subagent). It is built on the original fix by Alb11747 and Julius Marminge's takeover.

🤖 Generated with Claude Code

[github-actions]

Closing: Alb11747 already has 3 or more open PRs here, which is the limit for contributors who are not vouched.

Once one of them is merged or closed, open this again. See the open PR limit.

[chatgpt-codex-connector]

Codex Review Summary: ❌ Failed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	❌ Failed 2026-11-12T15:13:59.764658Z We couldn’t complete this review. Comment @codex review to try again.	00a0135	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[macroscopeapp]

🟡 Medium server/McpProviderSessions.ts:114

Registering or rotating provider instance B deletes every pending HTML render for the thread even while instance A still has a live session, so a late ACP completion for A gets undefined from takeHtmlRender and loses its page attachment. The condition checks only B's previous session, which is undefined on first registration; invalidate renders only when no other instance has a session.

Suggested change

	if (previous?.providerSessionId !== config.providerSessionId) {
	if (
	previous?.providerSessionId !== config.providerSessionId &&
	!Array.from(current.get(config.threadId) ?? []).some(
	([instanceId]) => instanceId !== config.providerInstanceId,
	)
	) {

🤖 Copy this AI Prompt to have your agent fix this:

In file @packages/provider-core/src/server/McpProviderSessions.ts around line 114:

Registering or rotating provider instance B deletes every pending HTML render for the thread even while instance A still has a live session, so a late ACP completion for A gets `undefined` from `takeHtmlRender` and loses its page attachment. The condition checks only B's previous session, which is `undefined` on first registration; invalidate renders only when no other instance has a session.

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — Provider switching now preserves each provider instance’s MCP tool credentials while retaining targeted revocation and full-thread cleanup. A reported HTML attachment-loss issue remains subject to the separate blocking correctness gate.

Needs human approval because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}