[BUG] [SECURITY] "Log out all sessions" + Claude Code instance revocation via claude.ai does not invalidate OAuth tokens — confirmed after 3-4 days and VM cold boot

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40271
2. https://github.com/anthropics/claude-code/issues/34198
3. https://github.com/anthropics/claude-code/issues/42342

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of the suggested issues. Here's why:

| Issue | Scope | How #43801 differs |
|---|---|---|
| #40271 | Browser session cookies survive "End session" in Active Sessions | #43801 is about Claude Code extension OAuth tokens, not browser sessions. Different auth mechanism, different credential storage, different revocation path. |
| #34198 | claude logout CLI doesn't revoke tokens server-side | #43801 is about the web-based "Revoke all" mechanism on claude.ai/settings/claude-code — the explicit, user-facing security control — not the CLI logout command. |
| #42342 | Remote session management feature request | #43801 is a bug report documenting that existing revocation controls don't work, not a feature request for new ones. |

The critical distinction: Those issues discuss missing or broken client-side revocation. This issue proves that even the server-side, web-based, explicit revocation UI — the last line of defense in a token theft scenario — fails to invalidate tokens. The offline VM (no network for 1-2 weeks) eliminates client-side token refresh as an explanation.

These issues are related (same problem space), but each documents a different failure point in the token lifecycle. Closing this as a duplicate would leave the web-based revocation failure undocumented.

I can confirm this issue. I have also done server-side revocation and it does not work. And my own #34198 is a feature request. This is actually a high priority security issue. I hope it gets the urgent attention it deserves.

Any updates on this?

this is a high severity issue not a dupicate one , i once logged in a friends device through a vscode extension and even after revoking all he is still able to access claude and he said this because he is a friend , he accidentally used up my session limit

I'm a bit surprised this issue has existed for a month now. It seems to me at this point that Anthropic are a bunch of amateurs. I'm switching to Gemini. This is not acceptable.

any updates on this ?

Bug still reproduces — additional confirmation after 21 days

Re-tested today (2026-04-26) with a stricter scenario than my original report:

Setup:

• Notebook with VSCodium + Claude Code extension authenticated via OAuth (Max plan)
• Notebook powered off for ~1 week (vacation, cold shutdown — no suspend, no network access at all)
• Only my desktop's Claude Code session was kept active during that period; every other session/device was revoked via claude.ai → Settings → Claude Code → "Revoke all"
• Notebook booted, VSCodium opened, Claude Code extension launched → fully functional, no re-authentication required, no 401

This rules out every conceivable client-side explanation:

• ✗ Background token refresh (machine was off, network disconnected at hardware level)
• ✗ Local credential repair (no daemon running)
• ✗ Race between revocation and last refresh (1 week gap)

The token was revoked server-side via the explicit user-facing UI, and the server accepted it on the next request after a week of cold offline state. This is a server-side token validation failure, period.

---

Re: recent changelog entries

I checked the changelog for the last 3 weeks. Several OAuth-adjacent fixes shipped, but none of them address this bug:

| Version | Entry | Relevance |
|---|---|---|
| 2.1.119 (Apr 23) | Fixed OAuth token refresh failing when the server revokes a token before its local expiry time | Client-side only. Assumes the server actually returns a revoked status — which it does not, per this report. |
| 2.1.117 (Apr 22) | Fixed Plain-CLI OAuth sessions dying with "Please run /login" when the access token expires mid-session — the token is now refreshed reactively on 401 | Arguably makes things worse: client now silently refreshes on 401 instead of forcing re-login. |
| 2.1.118 (Apr 23) | Fixed credential save crash on Linux/Windows corrupting ~/.claude/.credentials.json | Unrelated. |

The 2.1.119 fix is the closest to the issue space, but it presupposes that the authorization server returns a revocation signal. The bug reported here is that the authorization server does not enforce revocation in the first place — it keeps accepting tokens that the user explicitly revoked through the official UI.

---

Severity reminder for triage

This is now confirmed by multiple users (#43801, @tommycarstensen, @jagannath-p-s) and is 3 weeks old with zero Anthropic response. The "Revoke all" button on claude.ai/settings/claude-code is the user-facing security control for token theft and lost-device scenarios. In its current state it is non-functional.

For comparison, similar revocation bugs in OAuth providers (Google, GitHub, Microsoft) are typically treated as P0 / security-hotfix priority and fixed within hours to days. Three weeks of silence on a documented server-side revocation bypass is hard to justify.

Suggested minimum acknowledgement:

1. Confirm whether server-side revocation is implemented at all on the /oauth/token introspection path
2. If not, provide a timeline
3. If yes, provide a workaround for users in active token-theft scenarios

cc @bcherny — would appreciate any signal that this is being looked at.

are you gonna fix the damn problem or you gonna wait till it bites you harder?

Seems like its fixed now

Update — bug appears resolved server-side as of 2026-04-28 (silent fix, no changelog entry)

Re-tested today on Claude Code 2.1.121 (released earlier today, alongside 2.1.120).

Setup & observation:

1. Opened https://claude.ai/settings/claude-code → found a long list of stale Claude Code instances accumulated over months — every previous "Revoke all" had left them sitting there as active.
2. Revoked the entire list from the desktop.
3. Booted notebook (separate device), opened VSCodium with Claude Code extension.
4. Result: extension prompts for re-authentication, no functional access. 401 path is actually triggered. This is a clean reversal from every prior reproduction in this thread.

Caveats — read before celebrating:

• Short-cycle test (revoke → boot → re-auth prompt). The 1-week cold-off scenario from the original report has not been re-run since the apparent fix. In theory the result could also be explained by a shortened access-token TTL rather than full revocation enforcement at the introspection layer. Either way, observed behavior is materially better than before.
• Neither the 2.1.120 nor the 2.1.121 changelog (both shipped 2026-04-28) mentions a server-side OAuth revocation fix. The only OAuth-adjacent 2.1.121 entry is "Fixed /usage returning 'rate limited' after a stale OAuth token — now refreshes automatically", which is reactive client-side refresh, not revocation. Whatever changed here is infrastructure-side and undocumented.

Recommendation for everyone affected — @tommycarstensen @jagannath-p-s @oscarqjh @arifakhtar2026 @totekuh:

Open https://claude.ai/settings/claude-code right now. There is a non-zero chance you have months of stale Claude Code instances still listed as active — tokens that were never invalidated despite previous revocation attempts. Revoke the entire list, then re-test on a device you know was previously authenticated. If that device prompts for re-authentication, the server-side enforcement is working for your account too.

Anyone who lost, sold, traded-in, or replaced a device while this bug was live should assume those tokens were valid until today and rotate any related credentials accordingly. This is the first cleanup window we've actually had.

For Anthropic / @bcherny:

A silent server-side fix to a documented critical security bug is better than no fix, but:

1. Please confirm whether this is intentional and #43801 can be closed.
2. Backfill a changelog or security advisory entry. Users need to know to re-check their instance lists and rotate anything they had considered already-revoked.
3. Document the revocation enforcement model going forward — token introspection, short-lived access tokens with revocable refresh tokens, or both.

A month of public silence on a P0 auth bug, fixed without disclosure, is a worse outcome than the technical fix alone implies. The users in this thread were the ones doing your bug-bash unpaid; the minimum reciprocity is a one-line acknowledgement when it lands.

Unfortunately, I can still see this issue. I deleted all 950+ tokens using an automation, and as of now, have no active Claude code sessions as per https://claude.ai/settings/claude-code. However, my CC sessions is still active! Scary P0 :-(

<img width="1071" height="210" alt="Image" src="https://github.com/user-attachments/assets/25d5119e-88f0-4220-b2ca-e1681014d719" />

<img width="582" height="400" alt="Image" src="https://github.com/user-attachments/assets/4cdd6a8c-5acd-450a-b771-b699aa246d6e" />

Update: It got revoked after sometime (probably ~1 hour). Not sure if this is fixed or not as there is no official documentation.

ya fix this please, my claude usage 100% everyday now, someone keep using my claude, and i have no way to kick him out

<html><head></head><body>
<p><strong>Additional finding:</strong> The VS Code extension and Claude in Chrome extension OAuth tokens do not appear in the Authorization tokens list at <code>claude.ai/settings/claude-code</code> — making remote revocation impossible even after exhausting all available options.</p>
<p><strong>Environment</strong></p>

Component | Version
-- | --
macOS | 26.4.1 (25E253)
VS Code | 1.119.0 (Universal)
Claude Code extension | anthropic.claude-code v2.1.132
Claude Code CLI | Not separately installed — bundled via VS Code extension only
Claude for Mac | 1.6259.1
Claude in Chrome extension | 1.0.70 (Beta)
Chrome | 148.0.7778.97 (arm64, WebKit)

<blockquote>
<p>⚠️ Not yet tested in: Slack, JetBrains, or Claude design integrations (Figma/Sketch). Those extensions may be affected by the same issue.</p>
</blockquote>
<hr>
<p><strong>Steps to reproduce</strong></p>
<ol>
<li>Sign into the Claude Code VS Code extension with a Claude account</li>
<li>Attempt <code>/logout</code> and <code>/lo</code> commands in the extension — ❌ both fail with "no matching command"</li>
<li>Attempt sign out via Command Palette (<code>Cmd+Shift+P</code> → search "Claude Code") — ⚠️ clears local session only, token persists server-side</li>
<li>Navigate to <code>claude.ai/settings/account</code> → "Log out of all sessions" / "Terminate all sessions" — ❌ no effect on VS Code or Chrome extension tokens</li>
<li>Navigate to <code>claude.ai/settings/claude-code</code> → Authorization tokens — note that <strong>all tokens are generically labelled "Claude Code"</strong> with no device, extension type, or platform identifier</li>
<li>Revoked and deleted <strong>every visible token</strong> regardless</li>
<li>VS Code and Chrome extension sessions <strong>remained active after full revocation</strong> — ❌ server-side revocation had no effect</li>
<li>Claude for Mac <strong>1.6259.1</strong> token was listed and successfully revoked ✅</li>
</ol>
<hr>
<p><strong>Critical issue: tokens remain active and usable</strong></p>
<p>Despite exhausting every available revocation method, the VS Code and Chrome extension tokens were <strong>never invalidated</strong>. This means:</p>
<ul>
<li>❌ The account remains <strong>actively accessible</strong> via <code>anthropic.claude-code</code> in VS Code</li>
<li>❌ The account remains <strong>actively accessible</strong> via Claude in Chrome <strong>1.0.70</strong></li>
<li>❌ Both extensions can continue <strong>consuming account usage/quota</strong> under the authenticated account with no way to stop it remotely</li>
<li>✅ Claude for Mac was the only official Anthropic extension to appear in the token list and be successfully revoked</li>
</ul>
<hr>
<p><strong>The problem is twofold</strong></p>
<ol>
<li><strong>Tokens are not labelled</strong> — all entries at <code>claude.ai/settings/claude-code</code> are generically labelled "Claude Code" with no way to identify which token belongs to which extension, device, or platform. Targeted revocation is impossible.</li>
<li><strong>Revocation doesn't work server-side anyway</strong> — revoking all listed tokens had no effect on the VS Code or Chrome extension sessions. The sessions remained active and usable.</li>
</ol>
<hr>
<p><strong>Security impact</strong></p>
<p>A user signed into a personal account on a shared or work machine has <strong>no way to remotely revoke access</strong> for the VS Code or Chrome extensions. Even after:</p>
<ul>
<li>Revoking every visible token at <code>claude.ai/settings/claude-code</code></li>
<li>Terminating all sessions at <code>claude.ai/settings/account</code></li>
</ul>
<p>These extension tokens remain <strong>active and unrevocable</strong> from the account management UI — and can continue to be used to access and consume the account.</p>
<blockquote>
<p>The scope of affected official Anthropic extensions is likely broader than tested here. Slack, JetBrains, and design tool integrations (Figma/Sketch) have not been tested but may share the same token visibility and revocation gap.</p>
</blockquote>
<hr>
<p><strong>Recommendation</strong></p>
<p>All active OAuth tokens issued to <strong>official Anthropic extensions</strong> must:</p>
<ol>
<li>Be <strong>visible and clearly labelled</strong> in the Authorization tokens list at <code>claude.ai/settings/claude-code</code> — including extension name, platform, and device</li>
<li>Be <strong>individually revocable</strong> from that page</li>
<li>Be <strong>immediately invalidated server-side</strong> when "Log out of all sessions" is triggered from <code>claude.ai/settings/account</code></li>
</ol>
<p>This is consistent with how other platforms (Google, GitHub, Slack) handle connected app/device session management and is the expected baseline for any OAuth implementation.</p>
<hr>
<blockquote>
<p><em>Note: This report was written with the assistance of Claude (claude.ai) to ensure clarity and completeness. All steps, observations, and findings are my own.</em></p>
</blockquote></body></html>

+1, hitting this from a different angle.

I run Claude Code across multiple machines for testing and frequently need to bootstrap auth on a new box. The claude setup-token flow is the right primitive for this: generate an sk-ant-oat01-* token, drop it into CLAUDE_CODE_OAUTH_TOKEN, done. But the revocation side is currently too weak to lean on:

• Per this issue, revoking a token via claude.ai/settings/claude-code does not actually invalidate it server-side for days.
• /logout is local-only (see #34198); it deletes credentials on the machine but the token stays live.
• Running claude setup-token again issues another valid token alongside the first rather than rotating, and there is no CLI command to revoke a specific token by id/hash.

For anyone distributing tokens across machines (or rotating after a suspected leak), this means a leaked token is effectively non-revocable on a useful timescale, and the only fallback is a support ticket. Would value (a) the claude.ai revocation actually being honored server-side, and (b) #34198 landing so claude logout revokes rather than just forgets.

This is server-side issue, and it's now fixed.

Revoking a Claude Code token (including the "Revoke all" control at claude.ai/settings/claude-code) now takes effect promptly. It was a server-side fix, so no Claude Code update is required.

If you were affected, revoke anything you don't recognize at https://claude.ai/settings/claude-code. Revoked devices will be required to log in again the next time they're used.

or you can do that in bulk.

(async () => {
  const orgId = 'get this org id uuid';
  
  try {
    const listResp = await fetch(`/api/oauth/organizations/${orgId}/oauth_tokens`);
    const tokens = await listResp.json();
    
    // Log one token to verify structure if it fails again
    if (tokens.length > 0) console.log('Token structure:', tokens[0]);

    for (const token of tokens) {
      // Use token.id or token.uuid based on what the API provides
      const tokenId = token.id || token.uuid; 
      
      if (!tokenId) {
        console.error('Could not find ID for token:', token);
        continue;
      }

      const response = await fetch(`/api/oauth/organizations/${orgId}/oauth_tokens/${tokenId}/revoke`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(tokenId)
      });

      console.log(`${response.status === 204 ? 'Revoked' : 'Failed'}: ${tokenId}`);
    }
  } catch (err) {
    console.error('Execution error:', err);
  }
})();

This is server-side issue, and it's now fixed. Revoking a Claude Code token (including the "Revoke all" control at claude.ai/settings/claude-code) now takes effect promptly. It was a server-side fix, so no Claude Code update is required. If you were affected, revoke anything you don't recognize at https://claude.ai/settings/claude-code. Revoked devices will be required to log in again the next time they're used.

no, it's not fixed, because i just went there and literally nothing is working. nothing is being deleted. nothing is being revoked.

no, it's not fixed, because i just went there and literally nothing is working. nothing is being deleted. nothing is being revoked.

In my case it is working as expected. I am in EU servers however.

Confirming on a separate account 2026-06-20. claude.ai → Settings → Claude Code shows 872 entries (175 pages). Per-token delete does not remove them — list does not shrink on refresh. Federated sign-in, no password to rotate. remoteControlAtStartup: false confirmed as the per-session minting cause (#59378). Currently no working user-side mechanism to retire the backlog.

Is this fixed now?

any update?