After Hearing About Claude Token Theft, I Checked My Own Auth Tokens — and Found 27 of Them

I saw the news and felt a chill.

The story was about infostealer malware stealing Claude login sessions and using accounts without the owner’s knowledge. Some victims reportedly had their usage go from 0% to 100% within hours, without touching anything themselves.

I use Claude Code in VSCode every day. This didn’t feel like someone else’s problem, so I decided to actually check my own account.

I checked “Active Sessions” first, but…

Claude has a feature called “Active Sessions” that lets you see which devices are currently logged in. You can find it on claude.ai under Settings → Account.

But looking at it, I noticed something. This turns out to be session management for the browser-based chat interface — it’s a completely different thing from the Claude Code login I use in VSCode.

Digging further, I found that Claude Code has its own dedicated management page.

claude.ai/settings/claude-code

Opening this brings up a list called “Auth Tokens.” A new token is created every time you sign in to Claude Code, and revoking one signs that specific device out.

I opened it up, and there were 27

When I actually opened it, I was genuinely startled.

27 auth tokens, spread across 6 pages.

They ranged from “connected 47 minutes ago” to “connected on June 21” — nearly three months old. Honestly, I couldn’t tell you what most of them were even for anymore.

Looking closer, I noticed something else. The older tokens (from June and mid-August) had fewer scopes than the newer ones (from late August onward). Specifically, permissions like mcp_servers and sessions:claude_code were missing from the older tokens.

My guess is that as Claude Code added new features, the scope set attached to newly issued tokens kept growing. In other words, the old tokens are like “fossils” from before the current setup existed — and they’re just sitting there, never cleaned up.

What bothered me most looking at this list was that the only information available to judge whether a token is legitimate is the date and its scopes. There’s no device name and no location (IP address or region) shown. I had no way of telling, just from this screen, whether a token from July was me connecting from home or someone connecting from somewhere I’ve never been.

This “revoke” feature didn’t actually work until a few months ago

While digging through all this, I stumbled onto something even more unsettling.

On Claude Code’s issue tracker on GitHub, there was a report along these lines.

“Logging out of all sessions on claude.ai doesn’t actually invalidate Claude Code’s tokens” — reported back in April 2026.

• Log in to Claude Code via VSCodium
• Shut down the PC and leave it off for 1–2 weeks
• During that time, go to claude.ai and run “log out of all sessions” / “revoke all Claude Code tokens”
• Wait a few days, then restart the PC
• Result: Claude Code keeps working normally, using the token that was supposedly revoked

— complete with reproduction steps. There were comments from users who believed they’d been compromised, saying that no matter how many times they logged out, the unauthorized use wouldn’t stop. Reports of it “still not fixed” continued as late as the end of July.

Anthropic had apparently commented back in May that it was “fixed server-side,” but users kept reporting for more than two months afterward that it “isn’t working.”

So where does that leave things now?

Following the issue thread all the way to the end, I found that a developer had done a fairly thorough test in early August.

Rather than relying on indirect signals like the UI or usage numbers, the test called the API directly with a specific token immediately after revoking it. The result: the token was genuinely invalid within 5 minutes of revocation.

But there was an important caveat attached. Revocation happens “one token at a time,” and doesn’t affect other login methods (the desktop app’s /login, a separate setup-token, etc.).

In other words, it seems that some of the people reporting “it’s still not fixed” were actually logged in through multiple methods at once, revoked just one of them, and mistook the continued activity from a different login path as the same broken token still working. A mix of a real bug and a misunderstanding, apparently.

So what can we actually do about it?

Here’s a summary of what I learned digging into this.

If you use Claude Code in VSCode, checking only the first one is pointless. I almost fell into that trap myself, glancing at Active Sessions and thinking “looks fine.”

Also, if you know you’ve signed in through multiple methods (extension, CLI, setup-token), it’s worth remembering that revoking one suspicious-looking token doesn’t necessarily kill the others.

Honestly, what struck me hardest here is that this list alone doesn’t give you enough to tell whether a token is really yours. No device name, no location — out of 27 entries, I basically have to trust my own memory to know which ones are legitimate.

The original article said users have no effective way to defend themselves, and the more I looked into this, the more I think that’s not far off. At the very least, next time I clean up my tokens, I’ll start by being suspicious of the oldest ones.

If you use Claude Code in VSCode, it might be worth taking a look at claude.ai/settings/claude-code yourself. Like me, you might find more sitting there than you expected.