Skip to content

Claude tab: 'could not verify authentication status' when user is on Max OAuth (apiKeySource="none") #2653

Closed
Closed
Claude tab: 'could not verify authentication status' when user is on Max OAuth (apiKeySource="none")#2653

Description

@kevinhsykes
kevinhsykes
opened on May 12, 2026

Environment

  • T3 Code v0.0.23 (winget) on Windows 11
  • Claude Code CLI 2.1.139 (claude --version)
  • Authentication: Max plan via OAuth (~/.claude/.credentials.json), no ANTHROPIC_API_KEY set in user/machine env
  • SessionStart hooks configured in ~/.claude/settings.json (cap-guard, ready-queue summary, workspace-root-guard)

Symptom

Opening the Claude tab and sending any prompt returns could not verify authentication status from initialization result. No assistant content rendered.

Likely root cause: misinterpreting apiKeySource: "none"

Running the same command t3code presumably spawns:

claude --print --output-format stream-json --verbose "say only pong"

…with ANTHROPIC_API_KEY unset (i.e. an OAuth/Max-plan setup) emits this init event:

{"type":"system","subtype":"init", ...,"apiKeySource":"none","claude_code_version":"2.1.139", ...}

apiKeySource: "none" is the expected value for OAuth/Max users — it means "no API key needed, OAuth is being used." Following events stream normally and the assistant returns the response cleanly:

{"type":"assistant","message":{...,"content":[{"type":"text","text":"pong"}], ...}}
{"type":"result","subtype":"success","is_error":false,"result":"pong", ...}

So Claude Code IS authenticated and DOES return content. T3code's init parser appears to treat apiKeySource: "none" as "no auth resolved" and throw before consuming subsequent events.

Contributing factor: SessionStart hook events come BEFORE the init event

If the user has SessionStart hooks configured, claude emits hook lifecycle events first:

{"type":"system","subtype":"hook_started","hook_name":"SessionStart:startup", ...}   x N
{"type":"system","subtype":"hook_response","hook_name":"SessionStart:startup", ...}  x N
{"type":"system","subtype":"init", ...,"apiKeySource":"none", ...}
{"type":"assistant", ...}

T3code may also be hitting a timeout or first-event mismatch on the hook events before reaching the init event.

What works (confirmed)

  • claude --print "say pong" returns pong cleanly from the same shell (with ANTHROPIC_API_KEY cleared)
  • Claude Code is fully authenticated; the credentials file is valid; the result stream event reports total_cost_usd > 0 (real billing under the Max plan)

Suggested fix

  1. In t3code's init-event parser, accept apiKeySource: "none" as valid auth (OAuth path)
  2. Skip type: "system", subtype: "hook_started" and hook_response events when scanning for the init event

Possibly related

Same renderer bucket as #2652 (OpenCode tab assistant messages save to opencode.db but don't render). v0.0.23 alpha may have multiple init/parser bugs across provider tabs.

Activity

  1. kevinhsykes commented on May 12, 2026

    @kevinhsykes
    kevinhsykes
    on May 12, 2026
    Author

    Exact UI string (for codebase grep):

    Claude — Limited. Could not verify Claude authentication status from initialization result

    The "Limited" prefix suggests t3code has a degraded-provider state distinct from a hard failure. In this state the Claude tab is unusable (no messages render), but the provider isn't fully unloaded. Likely the same code path that emits this banner when other auth checks fail.

  3. jstephencorey commented on Jun 8, 2026

    @jstephencorey
    jstephencorey
    on Jun 8, 2026

    I have the same issue, where claude is logged in and works just fine run normally, but won't authenticate in t3 code.

    I'm on Windows 11, I got t3 code via the download from the website, and I'm currently on version 0.0.25 (though it hasn't worked in previous versions, either.

    I'm using an enterprise licence, and claude auth status returns:

    { "loggedIn": true, "authMethod": "third_party", "apiProvider": "bedrock" }

    Changing the settings to point to the binary at C:\Users\<user>\.local\bin\claude.exe, as maicotc-ulbra recommended, doesn't help.

    I currently don't have my HOME path set up, so I'm unsure if that has any effect.

  4. TheGP commented on Jun 15, 2026

    @TheGP
    TheGP
    on Jun 15, 2026

    Same issue

  5. matej-kaska commented on Jun 25, 2026

    @matej-kaska
    matej-kaska
    on Jun 25, 2026

    same issue

  6. hotpheex commented on Jun 28, 2026

    @hotpheex
    hotpheex
    on Jun 28, 2026

    Hitting this on Linux too (headless server), so it's not just a Windows thing.

    My setup: t3 running headless in a container, Claude CLI 2.1.195, OAuth via CLAUDE_CODE_OAUTH_TOKEN (team plan, no ANTHROPIC_API_KEY).
    claude -p "say OK" works fine and claude auth status is valid, but the provider card still says "Could not verify Claude authentication status from initialisation result".
    My build has zero apiKeySource references, so I'm on the probeClaudeCapabilities -> query().initializationResult() variant rather than the init parser one.

    For me it's purely a timing thing. The probe wraps initializationResult() in CAPABILITIES_PROBE_TIMEOUT_MS = 8_000, but the SDK init just doesn't return that fast here. I timed the init event directly:

    • Full config (plugins + SessionStart hooks + MCP): 10.4s, 10.9s
    • SessionStart hook off: 7.96, 8.28, 8.45, 9.21, 9.75, 8.22 (1/6 under 8s)
    • All plugins and MCP off: 7.09, 9.16, 8.16, 8.19, 8.54, 9.89 (1/6 under 8s)

    So cold start floors around 7s and regularly drifts to 9 to 10s. I couldn't get it reliably under the 8s probe no matter how much I stripped back, it just sits on the line and flaps green/red. Since the probe uses settingSources: ["user","project","local"] it runs my SessionStart hooks, which added about 2s on their own.

    Feels like the same fix as #2274 / #2272 where the auth probe got bumped to 10s but doesn't feel like a root cause solution.

    Exposing these probe timeouts with env vars would be a bandaid fix.

  7. DibeX commented on Jun 30, 2026

    @DibeX
    DibeX
    on Jun 30, 2026

    Same issue on version 0.0.29-nightly.20260630.690. I’m using it on a Windows 11 machine with Claude Max sub. When this happens, I can’t use /skills; it recognizes only the built-in /model, /plan, and /default.

  8. nsxdavid commented on Jul 5, 2026

    @nsxdavid
    nsxdavid
    on Jul 5, 2026
    Contributor

    This thread has three different failure modes behind one message. Measurements for the Windows one, confirming @maicotc-ulbra:

    A. Windows + npm install: the SDK probe can't spawn claude at all.

    probeClaudeCapabilities hands the configured path (default "claude") to the SDK's pathToClaudeCodeExecutable, which spawns it with no shell and no PATH/PATHEXT resolution. On Windows, npm installs a claude.cmd shim. Result (Win 11, CLI 2.1.201, SDK 0.3.170):

    Path given to SDK Result
    claude (default) "native binary not found" in 9 ms
    full path to claude.cmd spawn EINVAL (Node 20.12+ blocks shell-less .cmd)
    ...\claude-code\bin\claude.exe works: account + 157 commands in 1.5 s

    The version probe uses resolveSpawnCommand (handles .cmd), which is why the card shows the right version while auth fails. The probe also swallows the error, hence "no errors in logs".

    B. @hotpheex's headless-Linux case: spawn succeeds, init just exceeds the 8 s probe timeout. Different fix.
    C. @jstephencorey's Bedrock case: exe-path workaround doesn't help, so likely a third mode.

    PR incoming for A: resolve the command on Windows and follow npm shims to the packaged claude.exe/cli.js. No auth logic touched (unlike #3559's fallback approach).

  9. patriksimms commented on Jul 6, 2026

    @patriksimms
    patriksimms
    on Jul 6, 2026

    Can confirm third failure mode @nsxdavid described, so usage via bedrock. I am on mac, t3code 0.0.28 and claude 2.1.201.

    claude auth status gives the same result as @jstephencorey

    Edit: maybe its something different for me. Forgot that I started using aws credentials in 1password vault and need to expose the credentials differently. Got normal claude working, but could not point t3code to the wrapper script as the executable

  10. codeduction commented on Jul 6, 2026

    @codeduction
    codeduction
    on Jul 6, 2026

    running claude directly on the project directory and making sure to accept permissions first opened up this to work.

    So it's possible the cli hasn't been approved for that current project.

  11. Ylandolsi commented on Jul 7, 2026

    @Ylandolsi
    Ylandolsi
    on Jul 7, 2026

    same here :

    Image

  12. Vesperino commented on Jul 21, 2026

    @Vesperino
    Vesperino
    on Jul 21, 2026

    Hey — managed to fix this on my end (Windows, Max plan). Sharing in case it helps someone.

    Digging into the bundle, I think both root causes in the original post are actually off on Windows — the real problem is one layer lower.

    TL;DR: the capabilities probe never reads apiKeySource at all, and it isn't the hooks. On Windows the Binary path points at the npm shim (claude.cmd), and the Agent SDK can't spawn a .cmd — it dies with spawn EINVAL before init ever comes back. Point the Binary path at a real claude.exe and the banner disappears.

    Correcting the two theories above

    • It's not apiKeySource: "none". probeClaudeCapabilities calls query({ pathToClaudeCodeExecutable }).initializationResult() and reads init.account (subscriptionType, tokenSource) — it never touches apiKeySource. The banner fires purely because resolveCapabilities returns undefined.
    • It's not the SessionStart hooks. I reproduced the probe with my hooks (superpowers + others) active and it returned in ~1.5s, well under the 8s timeout. Hooks aren't what's failing.

    What's actually happening

    • The version probe (shows v2.1.x in the UI) uses t3code's own shell-aware spawn, so it works.
    • The capabilities probe goes through the bundled @anthropic-ai/claude-agent-sdk and spawns pathToClaudeCodeExecutable without shell: true.
    • On Windows, spawning a .cmd/.ps1 without a shell throws spawn EINVAL (Node's post-CVE-2024-27980 behavior) → the promise rejects → resolveCapabilities returns undefined → status: "warning" → "Could not verify Claude authentication status from initialization result."

    So auth was never broken. OAuth/Max works, billing charges Max — the init just never comes back because the subprocess can't launch.

    Reproduced it standalone (same options t3code uses)

    BIN = claude.cmd  ->  THREW: spawn EINVAL                                             (4ms)   -> banner
BIN = claude.exe  ->  account = { subscriptionType: "Claude Max", apiProvider: "firstParty" } (1.5s)  -> OK

    The fix (user side)

    Point the Binary path at a real claude.exe, not the npm .cmd.

    The npm install (npm i -g @anthropic-ai/claude-code) only ships claude.cmd / claude.ps1, which always fail this probe on Windows. The native installer gives you a real exe:

    C:\Users\<you>\.local\bin\claude.exe

    You can get it by running claude update once — it installs/updates the native build there. Set that as the Binary path, restart t3code, and the banner is gone -> shows Claude Max.

    Suggested fix (t3code side)

    When spawning via the Agent SDK on Windows, resolve .cmd/.ps1 shims to a spawnable target or pass shell: true — the same handling the version probe already does. Accepting apiKeySource: "none" won't help on Windows, because the init never returns in the first place.

    Env: Windows 11, Claude Code 2.1.216, agent-sdk 0.3.195.

  13. EmoPorEmilio commented on Jul 27, 2026

    @EmoPorEmilio
    EmoPorEmilio
    on Jul 27, 2026

    for me the previous solution didn't work, I have it installed on npm (probably an old version?)

    I did
    claude doctor
    which showed I had it on
    C:\Users<username>\AppData\Roaming\npm\node_modules@anthropic-ai\claude-code\bin\claude.exe

    updated the path and is now working

  14. nsxdavid commented on Jul 29, 2026

    @nsxdavid
    nsxdavid
    on Jul 29, 2026
    Contributor

    My PR on this was closed without comment. Not sure what the plan is. Maybe the underlying infra changed and the PR was not relevant anymore.

  15. t3dotgg commented on Aug 27, 2026

    @t3dotgg
    t3dotgg
    on Aug 27, 2026
    Member

    Thanks for the detailed reports and follow-up diagnosis. We believe this is fixed by PR #3740, PR #3931, and PR #4466.

    T3 now resolves Windows npm Claude shims to a spawnable executable before the SDK starts. The capability probe also recognizes Bedrock accounts, has a bounded startup time, and skips user hooks that can block or alter authentication checks.

    I'm closing this as fixed as part of an automated pass on all open issues. If Max OAuth authentication still cannot be verified in a build that includes these PRs, please reply with the OS, Claude installation path, authentication type, and capability-probe error, and we can reopen it.

  16. t3dotgg
    closed this as completedon Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions