Sign up
View stargazers12Sign up

[Bug]: T3 MCP tools return Authentication required after switching providers back and forth, preventing PR linking#18852

opened9d agobySSrirajBehera

Before submitting

  • I searched existing issues and did not find an exact duplicate. Related issue #16565 is discussed below.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Observed in an existing thread; not yet reproduced in a fresh thread:

  1. Start a thread using Claude Sonnet 5.5 and complete several turns.
  2. Create pull requests and have the agent register them with link_pull_request. This initially succeeds.
  3. Switch the same thread to Codex GPT-6.1 Sol, complete turns, then switch back to Sonnet 5.5.
  4. Continue switching between these providers after completed turns.
  5. On a later Codex turn, create a PR and call link_pull_request.
  6. Call list_thread_pull_requests in the same thread.

Affected thread: e865d22d-5cba-4270-b721-3f4e5b5b5436, titled “Playwright PDF Reports: Stage 5”. Incident date: 2026-10-12 UTC.

Expected behavior

Switching providers between completed turns should preserve access to T3 Code’s MCP tools. The active provider should be able to register new PRs and retrieve the thread’s existing PR links.

Actual behavior

Earlier Claude turns successfully registered PRs #56, #57 and #58 in cobblestackhq/cobble-touchstone.

After repeated Claude/Codex switches:

  • Codex’s link_pull_request calls for PRs #59 and #60 returned Authentication required.
  • Codex’s list_thread_pull_requests calls returned the same error.
  • T3 browser tool calls also reported authentication failures, so this was not limited to PR registration.
  • Normal coding turns continued, and PR creation on GitHub succeeded.
  • I could no longer see linked PRs in the affected thread.

A subsequent read from another thread confirmed that PRs #56–58 are still stored as links on the affected thread. PRs #59 and #60 are absent from that list. The earlier links were not deleted. Why the existing links were no longer visible in my UI has not been established separately.

Impact

Major degradation or frequent failure

PR creation on GitHub works, but T3 registration and listing repeatedly fail in the affected session. Browser tools are affected too.

Version or commit

Currently installed desktop version: 0.0.46-nightly.20261012.3035.

The version at the exact moment of failure was not separately recorded.

Environment

macOS, T3 Code Nightly desktop.

Providers/models used in the same thread:

  • Claude Agent: claude-sonnet-5-5
  • Codex: gpt-6.1-sol

Logs or stack traces

These outputs were recovered directly from the affected thread’s recorded tool calls. Times below are UTC, from the items’ updatedAt values.

text
1Run 6 — Claude Sonnet 5.5
2link_pull_request(.../pull/56) -> alreadyLinked: false
3link_pull_request(.../pull/57) -> alreadyLinked: false
4link_pull_request(.../pull/58) -> alreadyLinked: false
5
62026-10-12T22:55:05.490Z — Run 15, Codex GPT-6.1 Sol
7t3-code.link_pull_request({
8 "url": "https://github.com/cobblestackhq/cobble-touchstone/pull/59"
9})
10-> [{"type":"text","text":"Authentication required"}]
11
122026-10-12T22:56:19.589Z — Run 15
13t3-code.list_thread_pull_requests({})
14-> [{"type":"text","text":"Authentication required"}]
15
162026-10-12T23:05:55.319Z — Run 17, Codex GPT-6.1 Sol
17t3-code.link_pull_request({
18 "url": "https://github.com/cobblestackhq/cobble-touchstone/pull/60"
19})
20-> [{"type":"text","text":"Authentication required"}]
21
222026-10-12T23:08:05.670Z — Run 17
23t3-code.list_thread_pull_requests({})
24-> [{"type":"text","text":"Authentication required"}]

Screenshots, recordings, or supporting files

Recorded provider sequence (run start times, UTC, 2026-10-12):

text
1Run 10 22:42:01 claudeAgent claude-sonnet-5-5
2Run 11 22:45:33 codex gpt-6.1-sol
3Run 12 22:46:58 codex gpt-6.1-sol
4Run 13 22:47:24 codex gpt-6.1-sol
5Run 14 22:48:47 claudeAgent claude-sonnet-5-5
6Run 15 22:50:02 codex gpt-6.1-sol [PR link/list failures]
7Run 16 23:00:22 claudeAgent claude-sonnet-5-5
8Run 17 23:02:29 codex gpt-6.1-sol [PR link/list failures]

Read-only verification from another thread on 2026-10-13:

text
1list_thread_pull_requests({
2 "threadId": "e865d22d-5cba-4270-b721-3f4e5b5b5436"
3})
4-> succeeds; lists cobblestackhq/cobble-touchstone #56, #57, #58
5-> all three have source: agent, state: merged
6-> #59 and #60 are not listed

No screenshot or recording was collected. The relevant evidence is included inline; the full thread contains unrelated project work and credentials and is not attached. No server-side credential trace has been collected. Credential revocation or reuse remains a hypothesis.

Related issues

#16565 describes a reused provider session retaining an MCP credential scoped to the other provider after switching back. Its demonstrated error is parent_not_active; this incident returns Authentication required, including for PR listing.

This may be another manifestation of the same credential lifecycle problem, but the thread history alone does not prove that. If maintainers consider it the same underlying defect, this report can be consolidated into #16565.

Workaround

No recovery workaround has been tested on the affected provider session. Reading its links from another thread succeeds, but does not restore the failed registrations or the affected thread’s UI.

Report prepared with assistance from Codex using the affected thread’s recorded tool outputs.

JJulius Marminge9d ago

Note

Grok responding on behalf of Julius.Thanks for the detailed timeline. I'm closing this as a duplicate of #16565. The root cause is the same, and only the error you see is different.

On main, each thread has a single MCP credential slot. When prepareMcpSession switches a thread to another provider, it calls revokeThread(threadId) before it issues the new token (ProviderSessionManager.ts). Once a token is revoked, McpHttpServer rejects it with a 401 invalid_mcp_credential, and the MCP client reports that as Authentication required. That's why the browser tools failed too: every T3 tool shares the same credential.

In your sequence (Codex runs 11–13, then Claude run 14, then Codex run 15), Claude's turn rotated the thread's credential. Codex's app-server only receives mcp_servers on thread/start/resume/fork, and a shared Codex session keeps an idle thread loaded for up to 30 minutes, so Codex kept calling with the revoked token. #16565 hits the other half of the same problem. There, a reused session keeps a token scoped to the wrong provider, so you get parent_not_active instead of a 401.

Open PR #17096 (which fixes #16565) predicts this exact Claude → Codex → Claude → Codex case in its "Known limits" section. A full fix needs either a credential per (thread, provider instance) or releasing the previous provider's session when you switch providers. I've noted on #16565 that this is the 401 form of the bug, so the fix should cover both.

Workaround: restart T3, or wait more than 30 minutes before switching back to Codex so it resumes the thread and picks up the current token. Your links for #56–58 are still stored. #59 and #60 were never written because those calls failed, so you can re-link them with link_pull_request after a restart.