Remove a Claude account

What it is

Removing an account in Omniscio deletes its credentials from the local config.json and takes it out of the account pool's rotation. Both login accounts (OAuth Claude.ai subscriptions) and API key accounts are removed the same way — a small trash-can icon at the right edge of each account row in Settings → Accounts, gated by a confirmation dialog. The removal is local only: it does not log you out of Claude.ai in your browser, it does not revoke the OAuth refresh token at Anthropic's end, and it does not delete the API key from your Anthropic Console — it only forgets the credentials stored on this machine. There is no "Recently removed" undo for accounts (unlike projects), so the dialog is the only safety net before the row vanishes.

You cannot remove your only account from this UI — the trash icon's click handler refuses with an error toast directing you to add another account first or sign out via the app menu. This is intentional: a zero-account state breaks every spawn and most AI features, and Omniscio steers you away from accidentally landing there.

Where to find it

Accounts live inside Settings: click the gear icon in the toolbar, or open the Settings virtual project from the Omniscio sidebar group, and pick Accounts — the first item in its sidebar. Login accounts are listed under Login Accounts and API key accounts under API Keys, and each row carries a small trash icon at its right edge, beside its Activate link.

How it behaves

How to use it

1. Open Settings → Accounts. Click the gear icon in the toolbar (or open the Settings virtual project from the Omniscio sidebar group). The first sidebar item is Accounts.

2. Find the account row. Login accounts are listed under Login Accounts (showing email, display name, plan badge, and 5h/7d usage bars). API key accounts are listed under API Keys (showing the name, email, and an optional 24h/7d/30d cost summary). The active account has a green dot and a faint accent-colored border; inactive accounts have a grey dot.

3. Click the trash icon at the right edge of the row. The icon is a small Trash2 (lucide) glyph that turns red on hover. Each row also has an Activate link (if not already active) and, for API key rows, a Check Limits button — don't click those by mistake.

4. Confirm in the dialog. A ConfirmDialog appears titled Remove Account with the message: "Are you sure you want to remove "<email or name>"? This cannot be undone." The confirm button is Remove (red destructive variant). Click it to commit, or Cancel to back out. There is no Undo toast — once you confirm, the row is gone and the credentials are wiped from config.json.

5. Trying to remove your only account. If only one account exists, clicking the trash icon shows an error toast: "Cannot remove the last account. Add another account first, or sign out via the app menu." The confirm dialog never opens. To get to a true logged-out state from a single-account install, use the app menu's sign-out path (which clears the active account but keeps the row) rather than this trash icon.

6. What happens to in-flight sessions. Removing an account does not terminate sessions in the running/streaming state on that account. The CLI processes already hold their auth credentials in environment variables and finish their current turn normally. However, two side effects kick in:

   • If the removed account was the active one, Omniscio auto-promotes another account to active (the first one in the remaining list) and runs a trimmed store-reset cascade — channels (gmail/sms/channels), recipes, and automations all reset because their state can plausibly reference the removed credential. Projects, dividers, sessions, drafts (text/images/chips), git, file-explorer, and other stores are not wiped — they're user-scoped and survive credential removal unchanged. (A manual account switch via Activate runs no cascade at all — switching is a narrow within-user refresh.)
   • The next time any of those in-flight sessions tries to send a new message and reuse its persistent CLI process, the load-bearing stale-account invariant in writeToStdin() notices that spawnAccountId doesn't match the new active account, force-kills the child, and respawns the session against the new active account's credentials. From the user's perspective the session keeps working — it just silently rebinds to a different account on the next turn.

7. What happens to ended/archived sessions. Sessions that ended, errored, archived, or paused before you removed the account keep their account_id in the database — the binding is historical and does not disappear. Reopening one of those sessions to send a new message will (a) try the recorded account, (b) discover it no longer exists, and (c) fall through to whichever account the pool picks now. There is no migration or rewriting of historical session rows.

8. What happens to a removed account that was pinned. "Pinned" in Omniscio is just "Activated" (see switch-active-account.md). When you remove the active account, the active flag automatically moves to the next remaining account — the pin clears for the removed one and a new account becomes the implicit pin. Nothing in the UI lingers as a stale pin pointer.

9. What happens if you remove the only login account but keep an API key. With Allow API Keys to Run Sessions off (the default), session spawn will fail and Omniscio will surface the all-exhausted banner — API keys are restricted to AI features only until you flip that toggle on. With it on, spawns route to the API key and you'll be billed per token. AI features (titles, suggestions, automations) keep working on the API key in either case. See account-pool.md for the full tier-list interaction.

10. What happens if you remove every account. Omniscio enforces the "can't remove your last account" guard from the UI, but the data model technically supports a zero-account state. If you somehow reach it (e.g. by editing config.json by hand, or via the app menu's sign-out flow), every session spawn will fail and the all-exhausted banner ("All accounts are at their usage limit") will lock at the top of the sidebar. Add an account via the Log In with Anthropic button in the Add Account card (Settings → Accounts), or paste an API key, to recover.

For agents

How it works

The trash icon in AccountSettings.tsx calls requestRemoveAccount(id, label), which checks accounts.length <= 1 and toasts an error if so, otherwise opens a ConfirmDialog with the account's email or name. On confirm, it calls useAccountStore.removeAccount(id) from account-store.ts, which records whether the removed account was the active one and invokes IPC.ACCOUNT_REMOVE. The handler in claude-provider.ts calls authService.removeAccount(parsed.id), which delegates to removeAccount() in config-store/accessors-accounts.ts — that function filters the account out of configData.accounts, and if the removed id matched configData.activeAccountId, it sets the active id to remaining[0]?.id ?? null and persists config.json. The renderer then re-fetches the account list; if the removed account was active, it also runs the trimmed resetAllDependentStores() cascade — gmail/sms/channels reset and re-init via their init() calls, recipes and automations reset (next view-mount will refetch) — and refetches usage with forceRefresh: true plus rate limits via checkLimits(). Manual account switches (via Activate) do NOT call this cascade — switching is a narrow within-user refresh that updates the account list, usage, and limits only. See .claude/memory/postmortems/account-switch-no-refresh-postmortem.md for the 2026-05 trim of this cascade.

There is no explicit kill-cascade for sessions on the removed account — that's by design. Sessions in-flight finish their current turn on cached env-var credentials, and the stale-account invariant in writeToStdin() (see account-management.md "Persistent Process Reuse & Stale-Account Invariant") catches any future reuse: every persistent-process write checks session.spawnAccountId === authService.getActiveAccountId(), force-kills the child if they differ, and respawns with fresh credentials from the new active account. A [stale-account-respawn] spawn=<oldId> active=<newId> — killing persistent process log line confirms the catch on every occurrence. The credentials themselves are wiped — safeStorage-encrypted tokens for the removed account no longer exist anywhere in config.json after the operation, but the OAuth refresh token at Anthropic's end is not revoked; if you sign in again with the same email, Omniscio reuses the deduplicated row in authService.login() (matching by email.toLowerCase()) and refreshes the credentials in place.

Related

• add-a-claude-account.md — adding an account back in (re-signing in with the same email updates the existing row instead of duplicating), and the per-row Replace action that swaps an API key in place — use that instead of remove-then-add when you just want to rotate a key (it keeps the row + its cost history and never trips the last-account guard)
• switch-active-account.md — what "active" means and how Activate / removal interact with the pool
• account-pool.md — the tier-list and the all-exhausted banner that fires if you remove the only capable account
• session-stuck-in-needs-you.md — what an in-flight session looks like when its underlying account vanishes mid-turn (rare, but covered)