---
title: Remove a Claude account
---

# 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](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](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](../../src/renderer/src/features/settings/sections/accounts/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](../../src/renderer/src/stores/account-store.ts), which records whether the removed account was the active one and invokes `IPC.ACCOUNT_REMOVE`. The handler in [claude-provider.ts](../../src/main/ipc/account/claude-provider.ts) calls `authService.removeAccount(parsed.id)`, which delegates to `removeAccount()` in [config-store/accessors-accounts.ts](../../src/main/services/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](../../.claude/memory/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](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](switch-active-account.md) — what "active" means and how Activate / removal interact with the pool
- [account-pool.md](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](session-stuck-in-needs-you.md) — what an in-flight session looks like when its underlying account vanishes mid-turn (rare, but covered)