How to Check Which Claude Code Account Is Active

Checking, per CLI

Claude Code

Run /status in a Claude Code session. It reports the authenticated account — email, organization and plan — along with version and configuration details. Use /usage separately when what you want is remaining capacity rather than identity; the two questions are related but the commands are not interchangeable.

Codex CLI

Run codex login status. Codex CLI caches its own login under ~/.codex/auth.json, independently of ChatGPT on the web, and the IDE extension shares that CLI authentication rather than holding its own.

What these commands cannot tell you

Both read local state. They report the identity the CLI believes it holds, which is the right answer almost always — but if a switch left the two stores inconsistent, a local read can faithfully report the wrong thing. The authoritative check is a request that the provider answers, which is why verification after a switch is worth more than verification before one.

Where identity is actually stored

There are three separate locations, and understanding the split is what makes the failure mode predictable rather than mysterious.

• The Claude Code-credentials Keychain item — the working credential. This is what actually authenticates a request, and therefore what determines which account is billed.
• oauthAccount in the .claude.json config file — the account metadata: email, account UUID, organization name. This is what /status displays.
• oauth:tokenCache and oauth:tokenCacheV2 in ~/Library/Application Support/Claude/config.json — cached token state.

Nothing enforces agreement between them. They are written by the same tool at the same moment under normal operation, so they agree under normal operation — and a switcher that writes a subset breaks that invariant silently.

How the two disagree in practice

This is not hypothetical. It was reported against Claude-Usage-Tracker in issue #175, in unusually precise terms: switching profiles correctly updated the Keychain credential — confirmed by reading subscriptionType back out of the Keychain and watching it change — while oauthAccount retained the previous profile's email, account UUID and organization name. The result was that /status displayed the wrong account after every switch. That issue has since been closed, but the failure class is the one to understand: the switch worked and the label lied.

The reason it is expensive is that nothing errors. There is no failed command to notice and no warning to dismiss. You look at the account name, see the one you expected, and work for three hours against a different subscription — sometimes one with pay-as-you-go overage enabled.

The defence is for the tool to verify rather than report. Limit Lifeboat confirms which account the CLI actually landed on after every switch, and rolls the switch back if it cannot complete that confirmation; when a safe rollback is not possible it keeps a protected recovery directory and says so rather than guessing. How the alternatives handle verification is covered in the switcher comparison.

"I switched accounts and it still says my limit is reached"

This is the most common way people discover the problem. In rough order of likelihood:

1. The switch did not complete. Check the active identity first. If it still names the depleted account, nothing else in this list applies.
2. An existing session is holding the old credential. A Claude Code session that started before the switch keeps the credential it started with. Restart the session — and note that on macOS an IDE extension tab may need reopening rather than just reloading.
3. You are reading the limit from a different surface. A limit message in the browser reflects the browser's session, not the CLI's.
4. The reading is stale. Usage figures are cached by every tool that shows them, including this one. A number from twenty minutes ago is not evidence about now — see why usage numbers disagree.
5. The second account is genuinely depleted too. Quotas are separate and provider-enforced. Switching gives you access to that account's own allowance; it does not pool, merge or extend anything. If both are spent, see what to do when the limit is reached.

Browser, desktop app and CLI are separate

Each surface holds its own session. Signing into claude.ai in a browser does not change which account Claude Code uses, and switching Claude Code does not sign the browser in or out. The same separation applies to chatgpt.com and Codex CLI, with the wrinkle that the Codex IDE extension shares the CLI's authentication and therefore follows a CLI switch.

This matters most in the employer-provisioned case, where the browser is signed into a work account and the CLI is meant to be on a personal one, or the reverse. Keeping that boundary visible is the subject of work and personal accounts, and where the policy line actually sits is covered in are multiple accounts allowed.

Questions and boundaries

Related guides

• Fixing Claude Code Login Expired and Repeated Logouts

  What causes the repeated Claude Code logout loop, the recovery order that works, and how to avoid re-triggering it.

• Claude Code Lost Your MCP Servers or settings.json

  Four things actually cause this, only one of them is Claude Code's own doing, and the recovery order matters more than the cause.

• How to Switch Between Claude Code Accounts on Mac

  The official login flow, why repeated logins get awkward, and how to change authentication without replacing the rest of your CLI configuration.

Something not covered here? Support lists the quick checks, and the guide index has the rest.