[BUG] VS Code extension exits with code 1 on first daily launch: org verification runs with expired OAuth token, no refresh attempt before fatal 401
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On a machine with server-side organization enforcement (Claude Team plan), the VS Code
extension fails on the first launch of the day with Claude Code process exited with. The startup sequence fetches policy limits, the OAuth profile, and validates the
code 1
organization using the expired access token, with no token refresh attempt before
these calls. All three return 401, and because org verification is treated as fatal, the
process exits:
05:28:35.890 [DEBUG] Policy limits: fetch failed (auth 401) — Request failed with status code 401
05:28:35.891 [DEBUG] Policy limits: Using stale cache after fetch failure
05:28:35.894 [ERROR] Failed to fetch oauth profile from OAuth token: [REDACTED] Request failed with status code 401
05:28:35.931 [ERROR] Failed to validate OAuth token: [REDACTED] Request failed with status code 401
Unable to verify organization for the current authentication token. This machine requires
organization <ORG-UUID> but the token could not be validated.Evidence that the token was simply expired, not revoked:
.credentials.jsonshowedexpiresAt= 01:02 local time (overnight expiry)- First launch was at 07:28 → 401
- Opening a new window immediately after the crash works fine. Verified that the
crashed process does NOT refresh credentials: after the crash, .credentials.json
still contained the old expired expiresAt. The new window's own startup refreshes
the token successfully. One possible explanation is a difference between init paths
(resuming a previous session vs. starting a fresh one), but I have not verified
this — I recall the error occasionally appearing on fresh windows too. What is
verified: the first attempt of the day validates the org with the expired token
without refreshing, and a subsequent attempt refreshes successfully.
- Full debug log contains no line matching "refresh" or "expire" before the 401s.
This reproduces every morning (token always expires overnight). Confirmed not caused by
Claude Desktop or by CLAUDE_CODE_OAUTH_TOKEN / ANTHROPIC_API_KEY (both empty).
No local C:\ProgramData\ClaudeCode\managed-settings.json exists — the org requirement
comes from server-side policy.
What Should Happen?
If the stored access token is expired, refresh it before running the policy-limits
fetch, profile fetch, and organization verification — or retry the verification once
after a refresh instead of exiting fatally.
Error Messages/Logs
Full extension output log attached (redacted).
[Claude VSCode.log](https://github.com/user-attachments/files/30216029/Claude.VSCode.log)Steps to Reproduce
- Machine bound to an organization (Claude Team plan, server-side enforcement)
- Let the OAuth access token expire (e.g. overnight)
- Launch VS Code and start a Claude Code session (resuming a previous session)
- Extension exits with code 1 and the log above
- Open a new window → works immediately
Claude Model
_No response_
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
1.127.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Environment
- Claude Code VS Code extension: 2.1.215 (also reproduced on 2.1.214)
- OS: Windows <10 Home 22H2>
- VS Code: <1.127.0>, portable install (a second, installed VS Code exists but is not involved)
- Auth: claude.ai OAuth login (Team plan), organization-bound machine
- CLI <2.1.215> is also installed via PowerShell; sharing the same
~/.claude credentials. Workaround: running claude -p "ok" after boot refreshes the
token and the extension then starts cleanly.
Related issues
- #56935 — same org-verification code path fails hard, but for a different reason
(setup-token lacking user:profile scope). In my case the token has full scope
but is simply expired; verification runs before any refresh attempt.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Update: not specific to resumed sessions
Additional testing with an expired token (before any Claude surface touched it):
no session list) also fails with the same 401 / "Unable to verify organization"
error — repeated attempts in a row all fail, no refresh is triggered.
refresh, after which everything works.
So the difference is the entry point, not resume vs. fresh session: the direct
window/session startup path validates the organization with the expired token and
never attempts a refresh, while the session-list path refreshes correctly.
(Preliminary — single morning of testing on 2.1.218; will confirm with repeated
trials tomorrow. Today's run ended early because starting Claude Desktop refreshed
the token, which also confirms the shared credential store works as expected.)
Confirmed: entry point determines whether a refresh happens
Repeated the test today with an expired token, multiple consecutive attempts:
every single one failed with the same 401 / "Unable to verify organization" error.
None of them attempted a token refresh.
picker)** — that alone triggered a token refresh, and everything worked from then on.
So this is now verified, not preliminary: the direct window-on-file startup path never
refreshes an expired token before org verification and fails hard every time, while the
session-picker path refreshes correctly. The fix is presumably to run the same refresh
logic (or a refresh-then-retry on 401) in the direct startup path before treating org
verification failure as fatal.
Environment for this test: extension 2.1.218, VS Code 1.130.0 (portable), Windows.
I have full debug logs from both runs (one with 2 failed windows, one with 2 failed
windows followed by the successful session-picker refresh). Happy to attach them or
share specific excerpts if useful.
Thanks for the very detailed report and the follow-up testing.
We couldn't reproduce this in a black-box test on 2.1.233: it needs Windows + the VS Code extension + a Team-plan account with the organization requirement enforced server-side + an access token that has already expired, and we don't have that combination in our test setup. The attached log link also returns 404 for us.
From what you describe this looks like a real bug: the CLI that the extension spawns should refresh an expired token before verifying the organization (the standalone
claudeCLI does, as you observed withclaude -p "ok"), and the fact that aclauderun in a terminal or the session picker fixes it points at something specific to the extension-spawned process.To pin it down, could you share (with an expired token, before opening the session picker or a terminal):
claude doctorand the CLI version the extension is using (extension 2.1.233 if possible).%USERPROFILE%\.claude(e.g..lock,.oauth-refresh*) right after a failed launch.CLAUDE_CONFIG_DIR,HOMEorUSERPROFILEdiffer between your PowerShell and VS Code's environment.We'll keep this open as a bug.
🤖 Generated with Claude Code
We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.