Repository navigation
[Bug]: Claude auth failure renders as plain result text with no re-login affordance #7878
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Have the Claude provider working in T3 Code.
- Log out of Claude Code in a terminal (
claude auth logout, or/logoutin the CLI). An OAuth session that expires and fails to refresh produces the same state. - Send a message in an existing T3 thread on the Claude provider.
Expected behavior
T3 recognizes this as an authentication failure and surfaces something actionable: a "Claude is signed out" state with a log-in action (or at minimum a pointer to Settings → Providers and the CLI command), and the provider marked unauthenticated.
The failure is distinguishable from a normal failed turn, so the user knows the fix is re-authentication rather than a retry.
Actual behavior
The turn ends with the SDK's raw result string rendered as the assistant's reply:
Failed to authenticate: OAuth session expired and could not be refreshed
That is the entire response. The only affordance on it is the "Copy to clipboard" hover button. There is no log-in action, no link to provider settings, no retry, and nothing indicating the problem is outside the app. A user who does not already know to open a terminal and re-run claude auth login has no path forward from inside T3 — which matters most on mobile / T3 Connect, where there is no terminal to go to.
The information needed to do better is already present. The SDK marks this failure distinctly:
{"error":"authentication_failed","is_api_error_message":true}
{"result":"Failed to authenticate: OAuth session expired and could not be refreshed","type":"result"}
Grepping the shipped desktop bundle for OAuth session expired returns zero matches, so the string is passed through verbatim and nothing in T3 classifies it. This looks like a missing branch on error === "authentication_failed" rather than missing detection. The marker may need to be plumbed from the provider adapter in apps/server for the web timeline to render a distinct state.
Impact
Major degradation or frequent failure
Version or commit
T3 Code Nightly 0.0.34-nightly.20260819.1133
Environment
macOS 26.6.1 (Darwin 25.6.0) arm64, T3 Code Nightly 0.0.34-nightly.20260819.1133, Claude Code 2.1.239, Claude provider on claude.ai Max OAuth
Logs or stack traces
{"error":"authentication_failed","is_api_error_message":true}
{"result":"Failed to authenticate: OAuth session expired and could not be refreshed","type":"result"}Screenshots, recordings, or supporting files
The thread shows the user's prompt, then a single unstyled line reading ...uthenticate: OAuth session expired and could not be refreshed, with a "Copy to clipboard" tooltip overlapping the start of the text. No other controls are rendered.
Workaround
Re-authenticate in a terminal (claude auth login), then start a new thread or restart T3 — per #6022, open threads hold stale sessions and keep reporting the old auth state after credentials are fixed.
Related, but distinct:
- [Bug]: Claude provider credentials wiped (claudeAiOauth emptied, refresh token destroyed) after T3/CLI updates — recurring 'OAuth session expired and could not be refreshed' #6022 — a cause that produces this same string (credentials wiped, refresh token destroyed). This issue is about how the failure is presented, whatever the cause.
- [Bug]: Claude Settings reports authenticated while the launched CLI is logged out #7690 — Settings reports Claude authenticated while the launched CLI is logged out.
- [Bug]: Prompting a not logged-in Claude makes the message invisible in the GUI #4225 — prompting a logged-out Claude makes the user's message invisible in the GUI.
Activity
JamesDimonaco commentedon Aug 25, 2026
Yes i'm having this issue as well, I can't get claude to work at all, even though it's working fine on the claude code cli
no matter if i close t3code or logout of claude code and back in any variation i'm unable to send messages in t3code without the error "Failed to authenticate: OAuth session expired and could not be refreshed"
my version: 0.0.34-nightly.20260824.1174
borzaka commentedon Sep 6, 2026
After relogin in CLI (
/login) I was able to continue my session after T3 Code restart and entering the same prompt.Version 0.0.38
t3dotgg commentedon Oct 2, 2026
Note
🤖 GPT-6.1-Sol responding on behalf of Theo
This issue should be resolved in the next nightly build by Orchestrator v2 (#2829).
Please try that nightly. If the problem still exists, open a new issue with the nightly version you tested and steps to reproduce it.
ViperJuice commentedon Nov 11, 2026
Additional recovery-UX evidence from current CLI-backed multi-account provider setups. This does not claim that the original raw-result rendering bug is unchanged, or that a sign-in button was deliberately removed.
Environment: T3 Code nightly
0.1.9-nightly.20261111.4501; Claude Code2.1.322; two separate Linux server environments with account-specificCLAUDE_CONFIG_DIRdirectories.Two account profiles stopped authenticating. T3 now provides useful, account-specific guidance (an improvement over the original report), approximately:
Fresh native CLI auth-status probes in those exact account contexts independently returned exit 1,
loggedIn: false, andauthMethod: "none". Later probes returned authenticated subscription status. We have not established the underlying sign-out cause or verified recovery of an existing failed thread after re-login.The remaining UX problem is the path from the failure to account-scoped reauthentication. In this user's CLI-backed provider configuration, the visible recovery is still a terminal command, and a plain
claude auth loginin an ordinary terminal can target a different account directory. Users need to preserve both the environment/machine and the account-specific config directory.Separately, an earlier user-supplied Windows Providers screenshot showed a configured Codex instance's unauthenticated state and manual
CODEX_HOME/ shadow-home settings, but no Sign in action. That screenshot was supplied before the 4501 rollout; it is not a reproduction of the Windows UI on 4501, nor evidence that every Claude provider settings panel has the same layout.A useful recovery affordance would open an interactive login terminal on the selected environment with the configured account directory and working directory already scoped, then recheck provider status. It should not create a replacement provider instance, sign out other accounts, or silently fall back to API-key billing. This would address the discoverability problem without requiring T3 to store or handle the browser credentials itself.
Related but distinct: #18554 concerns stale per-thread Claude processes after a successful re-login; we have not reproduced that sequence here. anthropics/claude-code#88583 concerns credential loss; our Linux observations do not prove that specific wipe/race mechanism.