Aident AI

Claude for Chrome Still Logged In After Logout? Contain It
If Claude for Chrome still works after you use Log out of all devices, treat the extension as a separate authorization boundary. Stop browser automation, record the non-secret evidence, revoke Claude's site permissions, disable or remove the extension from every Chrome profile, terminate the account sessions and Claude Code authorizations you can see, and contact Anthropic Support for server-side containment.
Do not assume that removing the extension or clearing browser data revokes a copied OAuth credential. Current reports show that Claude for Chrome can remain authenticated after the account-wide logout, and the extension-specific grant may not appear in the normal Active sessions or Claude Code authorization lists. Only Anthropic can confirm and invalidate a server-side token family that is not exposed to you.
Use this order:
Confirm the extension really survives the logout, without sending a prompt.
Inventory every browser profile that has the official extension.
Remove Claude's approved-site access and disable the extension locally.
Use Claude's documented account and Claude Code revocation controls.
Preserve a short incident timeline and escalate unexplained usage or access.
Match the Exact Problem
This guide applies when all of these are true:
you used Settings > Account > Log Out on the Claude web app;
web, mobile, or desktop sessions require authentication again;
Claude for Chrome in an existing browser profile is still signed in or usable;
no distinct Claude for Chrome grant appears under Active sessions or Settings > Claude Code.
That sequence is different from an extension login loop, a browser-to-desktop bridge error, an expired Claude Code token, or ordinary site-permission prompts. If the extension says it is disconnected and cannot act, use Anthropic's Claude in Chrome troubleshooting instead.
The public reports establish a revocation and visibility gap. They do not prove that Claude for Chrome caused every case of unexplained usage. A copied browser credential, another Claude client, a scheduled task, a connector, a metering defect, or an already-running remote job can look similar from the usage page.
Before You Change Anything
If you suspect account compromise, stop using the affected Chrome profile for email, banking, cloud consoles, source control, or other sensitive sites. Do not ask Claude to investigate its own browser access.
Record:
the current UTC time;
the Claude for Chrome version and extension ID;
the browser profile name and operating system;
the time you selected Log Out;
which other Claude clients required a new login;
whether the extension remained signed in;
the usage-meter value and reset time;
any unfamiliar Active session, Claude Code authorization, connector, or scheduled task.
Do not copy cookies, access tokens, refresh tokens, extension storage, complete browser profiles, or private browsing history into an issue or support chat.
The official Claude for Chrome extension ID reported in the current issue is:
Confirm the installed item at chrome://extensions rather than installing a similarly named extension from a search result.
Step 1: Verify Without Performing an Action
Open the Claude for Chrome side panel in the affected profile. Do not send a message, open a sensitive page, or approve an action.
Record only what the panel shows:
signed in and ready;
sign-in required;
disconnected from Claude Desktop;
blocked by an organization policy;
another account or organization selected.
Expected result after a complete account-wide logout: the extension should require fresh authentication before it can access Claude. If it still shows the previous account as ready, the report matches the current extension-specific failure class.
Do not reproduce the problem in a production account by asking the extension to read or change a page. The visible authenticated state is enough for containment. If you are testing on behalf of a vendor or security team, use a dedicated test account and a blank local page.
Step 2: Inventory Every Chrome Profile
Chrome extensions are installed per browser profile. Disabling Claude in one profile does not prove that another profile, browser, or computer is clean.
For each Chrome profile:
Open
chrome://extensions.Turn on Developer mode only if you need to reveal extension IDs.
Find Claude and confirm the ID matches the official item.
Record the profile name, extension version, enabled state, and whether your organization manages it.
Repeat for other Chromium browsers you use, such as Edge, Brave, Arc, or Chromium.
Expected result: you have a finite list of profiles and devices to contain. An absent extension is not evidence that an OAuth artifact was never copied from that profile, but it prevents you from overlooking an enabled local client.
If the extension is force-installed or cannot be disabled, stop and contact your organization administrator. Do not edit managed browser policy or system files yourself.
Step 3: Remove Browser Access First
In the Claude extension side panel, open Settings > Permissions. Review Your approved sites, revoke every site you no longer want Claude to access, and change the action mode to Manually approve if the extension must remain installed during an investigation.
For an active containment event, disable the extension at chrome://extensions. If you do not need it for evidence, remove it from the profile. Close every Chrome window afterward so the extension process stops.
Expected result: the Claude side panel no longer runs in that profile, and Claude cannot initiate new local browser actions there.
This step limits local access. It does not prove that a server-side OAuth grant or a credential copied earlier is revoked. Do not delete profile directories or manually edit Chrome's extension storage. Those actions can destroy evidence and still leave a copied refresh credential usable elsewhere.
Step 4: Revoke Every Visible Claude Session
Sign in from a trusted browser profile at claude.ai, then open Settings > Account.
Review Active sessions.
Terminate unfamiliar or unnecessary sessions individually.
Use the account-wide Log Out control once.
Sign in again only on the trusted profile you are using for recovery.
Anthropic documents the account-wide control as signing out web browsers, mobile devices, and desktop applications. The extension-specific report shows why you must verify Claude for Chrome separately rather than assuming that description covers every OAuth grant.
Expected result: visible Claude sessions are terminated and require authentication again. Record any session that reappears unexpectedly, including its device, approximate location, and last-updated time.
Step 5: Revoke Claude Code Authorizations Separately
If you have used Claude Code, open Settings > Claude Code and delete every authorization you do not recognize or no longer need. Anthropic documents these tokens separately from the normal account session list.
Then close Claude Code on every machine you control. If you use subscription authentication on a trusted machine, run the normal logout command there:
Do not print or share ~/.claude/.credentials.json, Keychain entries, environment-variable values, setup tokens, or OAuth URLs.
Expected result: the visible Claude Code authorizations are gone, and each closed client requires a deliberate fresh login before use. This still does not expose or revoke an invisible Claude for Chrome grant.
Step 6: Contain the Identity Provider
If there is evidence of phishing, browser-profile theft, an unfamiliar session, or an account takeover, secure the identity provider you use for Claude:
change its password from a trusted device;
review recent sign-ins and recovery methods;
remove unfamiliar passkeys and sessions;
confirm multi-factor authentication is enabled;
review third-party account access and remove anything you do not recognize.
If you use an email login link, secure the email account first. If you use Google sign-in, follow Google's Security Checkup from the trusted profile.
Expected result: the login provider no longer accepts known-compromised sessions. This is necessary account containment, but it is not proof that an already-issued Claude OAuth refresh token was invalidated.
Do not rotate credentials repeatedly without a timeline. One controlled rotation plus session review produces better evidence than a sequence of unrecorded changes.
Step 7: Escalate the Server-Side Gap
Contact Anthropic Support through the Claude Help Center. Ask for an account-security review and server-side revocation of every Claude for Chrome access-token and refresh-token family associated with the account.
Include:
the UTC incident window;
the extension version and official ID;
the exact logout and verification sequence;
whether the extension remained authenticated;
usage values before and after containment;
the visible sessions and Claude Code authorizations you revoked;
whether scheduled tasks, connectors, or other clients were active;
a link to the extension-specific GitHub issue.
Do not send credentials or a complete browser profile. Offer sensitive identifiers only through a support channel that Anthropic confirms is appropriate.
Expected result: you have a support case that asks for the control only the provider can perform. If usage or paid charges continue after all local clients are stopped, preserve timestamped screenshots and billing records. Do not attribute the activity to the extension unless Anthropic correlates it to that OAuth client or grant.
Step 8: Verify Containment Across a Reset Window
Keep the extension disabled and all unnecessary Claude clients closed. At the next usage reset:
Record the starting usage value and UTC time.
Do not run Claude, Claude Code, Cowork, scheduled tasks, connectors, or the extension.
Check the meter at one or two planned times.
Record any increase without speculating about its source.
Expected result: usage remains unchanged while all known clients are idle. If it rises, add the before-and-after timestamps to the support case. A rising meter is evidence of unexplained activity, not automatic proof of credential theft or a specific client.
For Team or Enterprise, the owner can also disable Claude in Chrome at Organization settings > Claude in Chrome and apply a restrictive site allowlist. A managed Chrome administrator can block the extension for the affected organizational unit while the incident is investigated.
Common Failure Modes
Attempt | Why It Is Incomplete | Safer Next Action |
|---|---|---|
Use Log Out and assume every authorization is gone | Current reports show the extension can remain authenticated | Verify the extension separately and disable it |
Remove the extension and declare the token revoked | Local removal does not prove server-side revocation | Ask Anthropic to invalidate the token family |
Clear the whole Chrome profile immediately | It destroys useful evidence and affects unrelated accounts | Record state, then disable the one extension |
Revoke only Claude Code tokens | Claude for Chrome uses a separate authorization | Contain both surfaces and the account sessions |
Blame the extension for rising usage | Several clients and metering failures can look similar | Preserve timestamps and request provider correlation |
Publish raw extension storage | It can expose reusable credentials and private browsing data | Share only sanitized metadata through support |
Leave Automatically approve enabled | It permits broader action while you investigate | Revoke site permissions and disable the extension |
Why This Order Works
Claude's web session, Claude Code authorization, Chrome extension authorization, per-site permission, browser profile, and identity-provider session are different controls. A global logout can terminate one group without proving that every other credential family is gone.
The inventory finds every local client. Site-permission removal and extension disablement stop new browser actions. Account and Claude Code controls revoke what the product exposes. Identity-provider containment reduces the chance of fresh account access. The support case addresses the remaining server-owned credential boundary.
That is the useful pattern behind Aident's Ollama networking guide: match the exact symptom, answer early, test one boundary at a time, state the expected result, and distinguish a working containment step from an unproven root cause.
Verify One Managed Integration Boundary
After the account incident is stable, install or update Aident Loadout with:
Then run:
Inspect the selected schema, but do not execute it during the security check.
Expected result: one named Action is discoverable, its required connection and risk are visible, and no provider credential enters the prompt or shell output. This verifies a managed integration boundary without broad browser authority or an external write.
Set up Aident Loadout and inspect one managed connection.
Sources
How do I log out of all active sessions?, Anthropic Help Center, accessed August 2, 2026
Managing your active sessions, Anthropic Help Center, accessed August 2, 2026
Claude in Chrome permissions guide, Anthropic Help Center, updated August 1, 2026
Claude in Chrome admin controls, Anthropic Help Center, accessed August 2, 2026
Claude for Chrome OAuth grant remains authenticated after global logout, issue opened July 28, 2026
Claude Code OAuth tokens remain valid after logout and instance revocation, issue opened April 5, 2026
Unauthorized Claude usage continues after global logout, community report posted July 28, 2026
Claude usage reaches its limit while the account is idle, community report posted July 23, 2026
OAuth 2.0 Token Revocation, IETF RFC 7009
OAuth 2.0 Security Best Current Practice, IETF RFC 9700
Refresh this guide when Anthropic exposes Claude for Chrome authorizations in account settings, documents server-side extension revocation, or closes issue 82074 with a verified fix.


