[BUG] [SECURITY] Claude for Chrome OAuth grant remains authenticated after global logout and is invisible to session controls
Preflight Checklist
- [x] I have searched existing issues and found related reports (#43801 and #34198), but not this Claude for Chrome-specific revocation and visibility gap
- [x] This is a single security bug report: an OAuth grant remains usable after the account-wide logout controls that users reasonably expect to revoke it
- [x] The findings below were checked against the current official Claude for Chrome extension and independently reproduced
What's Wrong?
Summary
This issue is an important correction and extension of my original report. The evidence does not yet prove that a stolen Claude Code token caused the unauthorized usage. A stronger credential hypothesis has now emerged: the official Claude for Chrome extension can remain authenticated after Log out of all devices, while its OAuth grant is not shown in the Claude Code token list or the normal active-session inventory.
Official extension ID:
fcoeoabgfenejglbffodgkkbkcdhcgfn
This creates a containment gap: a user can change passwords, globally log out, revoke every visible Claude Code authorization, remove connectors and delete visible sessions, yet an extension OAuth grant may remain valid and invisible.
Independently reproduced behavior
A separate GitHub user reproduced the following sequence:
- The Claude web session was logged out.
- Claude Code required authentication again.
- Windows and Android Claude apps were logged out.
- Claude for Chrome remained authenticated and usable.
Relevant investigation comments:
- https://github.com/anthropics/claude-code/issues/82074#issuecomment-5117704222
- https://github.com/anthropics/claude-code/issues/82074#issuecomment-5117859449
- https://github.com/anthropics/claude-code/issues/82074#issuecomment-5118003687
Static evidence from the official extension
I reviewed the packaged code of official Claude for Chrome versions 1.0.81 and 1.0.84. The reviewed code indicates that the extension:
- requests OAuth scopes user:profile user:inference user:chat;
- stores accessToken, refreshToken and tokenExpiry in persistent chrome.storage.local;
- refreshes through https://platform.claude.com/v1/oauth/token;
- requests a duration of 31536000 seconds during authorization/refresh (the server may cap the effective lifetime);
- uses bearer-token authorization for Claude requests;
- on extension logout, removes local/session extension storage;
- does not make an observable OAuth revocation request in the reviewed logout path;
- does not show an observable sender-constrained/DPoP mechanism in the reviewed bundle.
These observations do not disclose any token or private credential. They show why deleting local extension data is not equivalent to revoking the server-side OAuth grant or its refresh-token family.
Real-world incident that exposed the gap
My account experienced continuing unauthorized quota consumption after a suspected credential-theft incident. Before observing the following window, I had changed passwords, repeatedly used Log out of all devices, revoked/deleted all visible Claude Code sessions and authorizations, removed local Claude clients and extensions, checked connectors and scheduled tasks, and monitored the local machines for Claude processes and network activity.
On 28 July 2026 (Europe/Madrid), with no message intentionally sent:
- 15:40 CEST — new five-hour window at 0%
- 15:41 — 6%
- 15:43 — 10%
- 15:46 — 24%
- 16:03 — 89%
- 16:13 — 100%
The Max-plan window was exhausted in approximately 34 minutes. Timestamped screenshots, hashes and forensic notes have been preserved. Sensitive identifiers and full evidence can be supplied privately.
Attribution: fact versus hypothesis
The following is established:
- quota increased rapidly without intentional user prompts;
- every user-visible revocation and logout measure had been applied;
- the Claude for Chrome authorization is not represented by the visible Claude Code authorization list;
- independent reproduction shows that Claude for Chrome can remain authenticated after global logout;
- the official extension maintains a refreshable OAuth credential locally.
The following remains a hypothesis, not a proven fact:
- that a copied Claude for Chrome OAuth artifact was the credential used during my incident.
Only Anthropic can confirm attribution by correlating inference requests with OAuth client/grant identifiers, token-family issuance, source IP, user agent and metering records. A backend metering or orphaned-worker defect remains an alternative explanation. The extension revocation gap is independently reproducible regardless of which explanation caused my usage incident.
This is related to #43801 and #34198, but adds a distinct affected client and control gap: Claude for Chrome can survive account-wide logout while remaining absent from the authorization surfaces the user is told to inspect.
What Should Happen?
- Log out of all devices must revoke all access-token and refresh-token families for Claude web, apps, Claude Code and Claude for Chrome—not only terminate visible web/app sessions.
- Claude for Chrome grants must appear in an account-level authorization inventory with issue time, last use, client type and an effective server-side Revoke action.
- Removing or logging out of the extension should revoke its server-side grant, not only delete local browser storage.
- Password reset and security-driven global logout should terminate pre-existing OAuth grants, or clearly warn the user if any grant is excluded.
- Revocation must also stop any already-running remote inference/job associated with that credential.
- Anthropic should be able to identify the OAuth client/grant that generated each metered request and provide that information during an account-compromise investigation.
Revocation should follow the security properties described by RFC 7009 and current OAuth security best practices:
Error Messages/Logs
No client-side error is displayed. The failure is silent: other Claude clients are logged out or require reauthentication, while Claude for Chrome can remain authenticated. In the incident window, the usage meter rose from 0% to 100% without an intentional message being sent.
Full forensic material is being preserved and will not be posted publicly because it contains account and incident metadata.
Steps to Reproduce
Use a dedicated test account and the official extension; no credential theft is required.
- Install the official Claude for Chrome extension (fcoeoabgfenejglbffodgkkbkcdhcgfn) and authenticate it.
- Confirm that the extension can access Claude.
- In claude.ai, use Log out of all devices.
- Revoke all Claude Code authorizations visible under Settings → Claude Code.
- Confirm that the web session and other Claude clients require authentication again.
- Open Claude for Chrome in the same browser profile.
- Observe whether it remains authenticated and able to access Claude without a fresh login.
- Inspect the account session/authorization pages and observe that no distinct Claude for Chrome grant is available for server-side revocation.
Expected: the extension requires fresh authentication, and its previous access/refresh token family is rejected server-side.
Actual: independently reproduced behavior shows that the extension remains authenticated after global logout, with no visible account-level control to revoke that grant.
Security Impact
If an attacker obtains the extension's bearer or refresh credential—for example through browser-profile theft or credential-stealing malware—the victim may be unable to terminate the attack using the security controls exposed by Claude. The attacker may retain access to inference/chat capabilities, consume paid quota, potentially access data within the granted scopes, and continue until the credential expires or Anthropic manually revokes the token family.
The core security impact is failure of incident containment: the product reports global logout while leaving an invisible, refreshable authorization usable.
The extension-specific technical report and evidence were submitted privately to Anthropic through HackerOne report #3899016.
Vendor confirmation
Anthropic has now confirmed through HackerOne that Claude for Chrome uses a separate OAuth authorization and that the gap in revocation and account session-control coverage for this authorization was already known internally before this report.
The security report was closed as a duplicate of that internal issue. This confirms the revocation gap described here, but it does not by itself establish which credential generated the unauthorized usage in my account. Anthropic has directed the account-specific attribution, token revocation and charge investigation to Support.
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
No known working version
Claude Code / Extension Version
Claude Code 2.1.220; Claude for Chrome 1.0.81 and 1.0.84 reviewed
Platform
Claude.ai, Claude for Chrome and Anthropic OAuth services
Operating System
Reproduced across browser/account session boundaries; incident environment includes macOS
Terminal/Shell
Not applicable to the extension-specific reproduction
Additional Information
Please treat the public issue as the reproducible product/control-gap report. Sensitive forensic evidence, account identifiers and incident artifacts are available through the private HackerOne report.
Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
<img width="999" height="708" alt="Image" src="https://github.com/user-attachments/assets/deab6538-6bcf-49af-ae94-1213606a6ed5" />
<img width="988" height="658" alt="Image" src="https://github.com/user-attachments/assets/4e5e021a-7201-4872-affd-bd350f18dcec" />
<img width="986" height="676" alt="Image" src="https://github.com/user-attachments/assets/7ac56e80-8c82-4506-8534-334cd0905c3e" />
<img width="981" height="586" alt="Image" src="https://github.com/user-attachments/assets/b5c4c74f-9a53-4a11-8cb7-6ba41e88f1f3" />
I am facing the same issue.
I have multiple PCs, and one got infected. This gave me an opportunity to test a few additional things because I could log out of all sessions and revoke all OAuth tokens from my Claude Code instances. After I did that, I checked what happened on the other systems, and here's what I found.
What seemed to work:
I'm not ruling out the possibility that there are still ways to bypass the above. However, another thing that definitely did not work was revoking the authentication for the Claude for Chrome browser extension.
Even after revoking all Claude Code OAuth instances and logging out of all sessions, my browser extension remained authenticated.
This can also be tested and reproduced by following these steps:
This means that Claude for Chrome sessions cannot be revoked through the web UI as they're not shown.
It’s true that it doesn’t appear as an active session when you launch the Claude for Chrome extension, but it may be designed so that you can enable or disable it within its own tab (Claude in Chrome):
<img width="941" height="446" alt="Image" src="https://github.com/user-attachments/assets/a076f7b7-6dfc-4be0-8d6b-a1d5e2c46805" />
Well sure, it's fine if it's on it's own tab, however I would still want to be able to revoke those leaked sessions and keep using Claude in Chrome myself instead of having to deactivate the entire feature account wide.
I'm unsure if this is the same thing for you, but in my case, it's likely that it's my Claude in Chrome cookie that's being used since that one is definitely still active.
It's something only Anthropic can see, but they haven't responded yet (started a support conversation over a week ago)
I’ve understood you now
Yes, it would definitely be a useful feature, as there may be several browsers, with different profiles, or on different devices
In my case, I also had the Chrome extension installed in several browsers (with different profiles) and perhaps that authentication is what was compromised, as you say
I also wrote to them a few days ago, but unfortunately I haven’t received a reply. I started a thread on HackerOne, but I’ve been told it’s supposedly a duplicate
Although we’re not sure whether it’s down to the Claude extension, Claude Code or some other authentication cookie
What else can we do?
I’m glad to have found someone to talk to about this, at least...
@uningeniero, if you also used the Claude for Chrome browser extension, then I would expect that it's indeed the browser extension cookie that can't be revoked which is being exploited.
What I ended up doing was cancelling my plan and creating a new account with a new subscription. It sucks, but until Anthropic responds, there's nothing else we can do because our main accounts are literally unusable right now.
I can only hope that, once they do respond, they'll refund all of the duplicate charges and transfer my remaining credits (or simply make my main account usable again).
I'd also say that this issue is definitely not a duplicate. Our issue is most likely related to the Claude for Chrome browser extension, and this is something that no other thread has discussed before. Additionally, those other threads are closed and appear to have been resolved. We have a similar issue with a different root cause, and that does not make it a duplicate of an issue that was closed a long time ago.
I hadn’t thought about the issue with the Claude Code extension for Chrome, and it makes a lot of sense to me, especially as I was logged in to several browsers using it.
I’m going to check that computer’s history to see if there’s anything from that time, and check whether the keychain is storing any cookies that could be exploited.
As for using it, I’m switching straight over to Codex. It’s unacceptable not to have a decent support and customer service in the year 2026.
Do you think it would be better to create a new issue, separate from this one, focusing specifically on the problem with this extension?
@uningeniero I'd wait and see what this current issue brings us and perhaps edit the description a bit to state that this is most likely related to the Claude browser extension rather then creating yet another issue.
I’ve just edited it – I think it looks great.
Nothing new here – still no reply from Anthropic.
How are things over there? Any news?
<img width="753" height="565" alt="Image" src="https://github.com/user-attachments/assets/aacf15ed-cc95-46dc-851b-b6f4074f9735" />
This is frustrating. It restarted today; it’s only been a few minutes and it’s already at 3% without me having touched anything, without logging in anywhere, and with everything in quarantine.