Claude Tokens Stolen? How to Check and Fix

If your Claude usage bar climbs while you are not touching it, the explanation is probably not a billing glitch. Anthropic has emailed affected subscribers to say that Claude tokens stolen through infostealer malware on their own machines are being spent by somebody else, and the company confirmed to one user that a compromised session key had been used to mint unauthorized Claude Code OAuth tokens.

Key Takeaways:

• The attack takes a login session, not a password, so two-factor authentication does not stop it
• Claude does have a session list now, at Settings then Account, and terminating an unfamiliar session cuts the attacker off immediately
• Claude Code authorizations are separate and have to be deleted separately, at Settings then Claude Code
• What Anthropic still does not offer is itemized usage, so you cannot see which session spent which tokens
• A web session on claude.ai lasts 28 days and refreshes hourly, which is why a single stolen cookie stays useful for so long

What actually happened to these Claude accounts

On 4 August 2026, Grant De Swardt, an independent AI consultant in East Sussex, noticed his Claude Max 20x usage rising on a day he had not worked. He shut off everything attached to the account the following day and watched it climb again. His description to TechCrunch is precise in a way that matters: "In the clearest controlled interval, it increased from 45% to 55% while I performed no work, scheduled Cowork tasks were paused or completed, Dispatch/cloud execution was disabled, and there was no corresponding active local Claude Code task."

He asked Anthropic for an itemized list of what had consumed the allowance. He did not get one. Anthropic did agree something was wrong, suspended the paid account, invalidated every session and server-side Claude Code token, and refunded £44.49 of the remaining month on his $200 subscription. His account came back roughly two weeks later. In the meantime, a business built on running agents for small and mid-size clients had no agents.

Other subscribers got a warning email instead. Two of them published it, and the wording is worth reading exactly as Anthropic wrote it:

"We have recently become aware of a bad actor that is using common infostealer malware to steal Claude login sessions from people's computers, then using those login sessions to access Claude accounts and consume their usage."

That single sentence explains the whole mechanism. An infostealer is ordinary commodity malware that sits on a machine and scrapes saved passwords, cookies and session data. It did not arrive through Claude; Anthropic said as much, and this class of malware usually rides in on a cracked installer or a poisoned ad. Once it has your session cookie, it does not need your password and it does not need your second factor, because both of those were already spent when the session was created. The session is the credential.

How to tell whether it is you burning the tokens

The uncomfortable part is that Anthropic tracks total usage but not itemized usage, so there is no report that says "this much came from a browser in another country." You are left with indirect evidence, and the reports that surfaced alongside De Swardt's have a recognisable shape. One person watched usage go from zero to 49% in twelve minutes after a couple of prompts and a web search. Another said their account "was auto-upgraded without my consent, my credit card got charged, and the usage shot from 0% to 100% automatically without me even touching it." A third burned the full daily limit three days running without opening Claude at all.

So the signal for Claude tokens stolen this way is not a number, it is a mismatch. Usage that moves when nothing of yours is running. Limits that land mid-morning when they used to land at six. A plan change or a charge you did not authorise. If you use Claude heavily every day you may genuinely not notice, which is the reason this could have run for months undetected.

Check your active sessions and terminate the ones you do not recognise

Most of the coverage got one thing wrong, and correcting it is the most useful paragraph here: Claude does have session visibility, and has since March. Anthropic's help centre page on managing your active sessions is dated 17 March 2026 and says plainly, "Previously, there was no way to see what sessions were active on your account." That changed. What has not changed is the itemized usage gap, which is a different complaint and the one that actually still bites.

Each session shows the device and browser, an approximate location from the IP address, and when it was last used. Click your profile icon at the bottom left, go to Settings then Account, and scroll to Active sessions. If a row says Chrome on Windows in a country you have never worked from, open its three-dot menu, choose Terminate, confirm, and that device is out.

If you would rather not read the list at all, there is a heavier hammer. Anthropic's page on logging out of all active sessions walks through Settings, Account, then the Log Out button, which signs you out everywhere including desktop applications. Note the limitation buried at the top of that page: this option is not available in the iOS or Android apps, so you have to do it from claude.ai in a browser.

Revoke the Claude Code tokens, because that is what got minted

Terminating browser sessions is not the end of it, and people stop too early right at this point. The stolen session key in De Swardt's case was used to mint Claude Code OAuth tokens, which live in a different place with a different lifetime. Anthropic's own instructions put them under Settings then Claude Code, where each authorization token has a trash can icon next to it; deleting the token logs Claude Code out.

Do that even if your session list looks clean, because a token minted last week survives a browser logout today, and it is the route by which Claude tokens stolen from a browser keep getting spent after you think you have locked up. The ordering that makes sense is: delete the Claude Code tokens first, then terminate the unfamiliar sessions, then change the password on the email address your Claude login link goes to. Reversing steps one and two leaves a window where the attacker simply mints a fresh token from the session you have not killed yet.

Why a stolen cookie stays useful for four weeks

Anthropic documents the session lifetime, and the number explains the economics of this attack. A login at claude.ai creates a session lasting 28 days, and any action on the site refreshes it back to a full 28 days from that moment. An attacker who is quietly using your account every day therefore holds a credential that never expires on its own. It only dies when you kill it, or when Anthropic does.

That is not unique to Claude; long-lived sessions are how most of the industry works, and the alternative is logging in constantly. It does mean the window between infection and discovery is measured in weeks, and it puts the burden of noticing on you.

Getting the malware off the machine that holds the credential

Rotating sessions on a compromised laptop buys you an afternoon, and every report of Claude tokens stolen in this wave started on a machine nobody had cleaned. The infostealer is still there, still reading the cookie jar, and the next session you create is the next one stolen. Anthropic said as much when it warned users they may have malware, and it removed saved payment methods as a precaution in at least some cases, which tells you what it thought the malware could reach.

Assume anything the browser had saved is gone: other AI subscriptions, cloud consoles, anything holding a session cookie. Run a real scan, and if the machine is one you use for client work, treat rebuilding it as the cheaper option rather than the paranoid one. Rotate credentials in order of blast radius, which for most people means email first, because email recovers everything else.

Worth saying plainly: De Swardt insists he found no evidence of compromise on his machine, and Anthropic could not determine how the account was accessed. So the malware story explains the emailed cases and may not explain every case. If you have terminated everything and usage still moves, you are in the same position he was, and the honest answer is that the tooling to prove it does not exist yet.

Why the credential is sitting on your laptop at all

Why do a $200 subscription's keys live on the same machine you use to download a random installer at eleven at night? Because that machine is where the agent runs. Long sessions exist so work continues; Claude Code holds an authorization because it acts on your behalf well after you stop watching.

That requirement does not go away, but the location can move. Running the agent somewhere that is not your daily browsing machine puts a boundary between the thing that gets infected and the thing that holds the authorization. Zentor is built on that shape: a hosted cloud AI computer where the agent and its credentials live on a machine you do not also use for email and downloads, sitting alongside your existing Claude subscription rather than replacing it.

The always-on part matters for the same reason. People keep sessions alive on a laptop because they want scheduled and overnight work to actually happen, and a laptop that sleeps cannot deliver that, so the workaround becomes a permanently logged-in machine. Zentor removes the reason for the workaround by keeping the machine up, which is a different argument from security but ends in the same place. If you are rebuilding a compromised laptop this week, the practical benefit of Zentor is narrower and more immediate: the agent work does not stop while you reinstall an operating system, because it was never running on that laptop, and you pick it back up from whichever device you happen to be holding. That is also the honest limit of what moving hosts buys you. It does not clean your machine, and it does not give you the itemized usage report that is genuinely missing from Claude today.

Our write-up on AI agent security risks covers the credential surface across agent tooling, and coding agent security deals with an agent being fed output it should not trust. For visibility into your own consumption, the Claude Code session manager piece fits closer.

FAQ

Why is my Claude usage maxed out when I did not use it?

The two plausible causes are an automation of yours still running, and somebody else using your account. Rule out the first by checking scheduled tasks and any cloud execution you have enabled, then check Settings, Account, Active sessions for a device or location you do not recognise. If a session you cannot account for is listed, terminate it before doing anything else.

Does terminating a session log out Claude Code too?

No. Claude Code authorizations are managed separately under Settings then Claude Code, and you delete each token with the trash can icon. This is the step that matters most for this particular attack, since compromised session keys were used to mint Claude Code OAuth tokens.

Does Anthropic refund stolen tokens?

It has in some cases. Anthropic issued refunds to users it proactively warned, and gave De Swardt a partial refund of £44.49 covering the unused part of his subscription. There is no published policy guaranteeing this, so treat it as a support conversation rather than an entitlement.

Can two-factor authentication prevent this?

Not on its own. The attacker takes a session that was created after your second factor was already satisfied, so the login step is never repeated. Session hygiene and keeping the machine clean are what actually help here.

How long does a Claude web session last?

28 days, and it refreshes to a fresh 28 days whenever you take an action on claude.ai. That is why a stolen cookie stays usable for as long as it does.

Claude tokens stolen is an account problem before it is a Claude problem

The conclusion from this batch of reports is that the security boundary was never Anthropic's login page; it was your laptop's cookie jar, and it failed. Delete the Claude Code tokens, terminate the unfamiliar sessions, clean or rebuild the machine. Then push for the piece that is still missing, because until per-session usage attribution exists, every subscriber in this position is reduced to arguing about percentage bars with support.