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

[kevinhsykes]

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.

[kevinhsykes]

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.

Workaround for Windows users

I hit this exact error on Windows 11 and got it working. For me it was not the apiKeySource / hook-parsing issue described above — on my installed build, apiKeySource doesn't appear in the code at all. The error comes from the Agent-SDK capabilities probe (probeClaudeCapabilities → query().initializationResult() in ClaudeProvider.ts) returning undefined.

The cause: the probe passes the configured binary path straight to the SDK, which spawns it without a shell. The default value is the bare string "claude", and on Windows that's really claude.cmd/claude.exe — a shell-less spawn("claude") can't resolve a bare name, so the probe throws and you get "Could not verify Claude authentication status from initialization result." (Notably the version check works and shows the right version, because that probe sets shell: true on win32 — only the capabilities probe doesn't.)

The fix that worked for me: point the provider at the absolute path to claude.exe.

1. In T3 Code settings, create a new Claude (claudeAgent) provider instance (or edit your existing one).
2. Set its Binary path to the full path of claude.exe, e.g.:

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

3. Fully quit and reopen T3 Code.

To find your own path, run one of these in PowerShell:

(Get-Command claude).Source        # shows the .cmd shim
Get-ChildItem "$env:USERPROFILE\.local\bin\claude.exe"

After switching from claude to the absolute claude.exe, auth verifies correctly and the Claude tab works. Auth itself (OAuth/Max plan via ~/.claude/.credentials.json) was never the problem.

Suggested code fix: in probeClaudeCapabilities, resolve the binary the same way runClaudeCommand already does (shell: process.platform === "win32") instead of handing a bare name to the SDK — and surface the probe error rather than collapsing it into a generic auth message.

[jstephencorey]

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.

[TheGP]

Same issue

[matej-kaska]

same issue

[hotpheex]

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.

[DibeX]

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.

[nsxdavid]

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).

[patriksimms]

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

[codeduction]

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.

[Ylandolsi]

same here :