claude-code-account-rotation

Account switching and quota dashboard for Claude Code.

A single local executable that serves a loopback web page showing every one of your Claude Max accounts with its 5-hour and 7-day headroom, ranks them by earliest weekly reset, and switches the whole machine to the account you pick, with no browser step. Every open Claude Code session follows the switch on its next request.

Status: a tagged release exists.

Posture

• Nothing calls the model API outside the unmodified claude binary.
• Credential pairs are moved between your own files on your own machine, never copied, so each refresh token exists in exactly one place. Handing an account to the other side of the same machine (a WSL distribution) crosses a volume, where a rename does not exist: there the pair is staged, verified by fingerprint, promoted and deleted under a journal, so at most one reachable copy exists at every instant. Nothing is ever copied to another machine.
• The tool identifies itself honestly on every request it makes.
• Every switch is a human click; nothing rotates on its own.
• The tool never calls the model API.
• It reads the undocumented usage endpoint with its own User-Agent, which the research rates GRAY (no Anthropic statement either way), not ALLOWED. It reads only when the dashboard is opened, Refresh is pressed, or the rate-limit stop hook fires, at most once a minute per account, never on a timer.
• The parked-pair refresh presents Claude Code's public OAuth client_id.
• Running the loop lanes (work-loop, babysit-loop, attend-queue) while rotating accounts is outside V1 because reader-side invalidation of a latched window is still an open problem.

Terms of service and compliance

Last reviewed: 2026-10-05.

This is the maintainer's reading of public sources, not legal advice. Anthropic "reserves the right to take measures to enforce these restrictions and may do so without prior notice" (legal and compliance), and it can change its terms at any time.

Sources

Source	URL	Effective or checked
Consumer Terms	https://www.anthropic.com/legal/consumer-terms	effective 2025-10-08, checked 2026-10-05
Commercial Terms	https://www.anthropic.com/legal/commercial-terms	effective 2025-06-17, checked 2026-10-05
Usage Policy	https://www.anthropic.com/legal/aup	effective 2025-09-15, checked 2026-10-05
Claude Code legal and compliance	https://code.claude.com/docs/en/legal-and-compliance	checked 2026-10-05
Claude Code authentication	https://code.claude.com/docs/en/authentication	checked 2026-10-05
Claude Code GitHub Actions	https://code.claude.com/docs/en/github-actions	checked 2026-10-05
Claude Code desktop app	https://code.claude.com/docs/en/desktop	checked 2026-10-06
Log in to your Claude account	https://support.claude.com/en/articles/13189465-log-in-to-your-claude-account	checked 2026-10-06
Supported countries	https://www.anthropic.com/supported-countries	checked 2026-10-05
Safeguards warnings and appeals	https://support.claude.com/en/articles/8241253-safeguards-warnings-and-appeals	checked 2026-10-05

What the terms say

• Consumer Terms §2: "You may not share your Account login information, Anthropic API key, or Account credentials with anyone else." and "You also may not make your Account available to anyone else."
• Consumer Terms §3 forbids access "through automated or non-human means, whether through a bot, script, or otherwise", "Except when you are accessing our Services via an Anthropic API Key or where we otherwise explicitly permit it".
• Legal and compliance: "Advertised usage limits for Pro and Max plans assume ordinary, individual usage of Claude Code and the Agent SDK."
• Legal and compliance: "developers may not collect, store, or intermediate Claude.ai credentials or session tokens — sign-in to a Claude account must complete through Anthropic's own flow".
• Legal and compliance: the restriction does not "prevent an end user from signing in to the unmodified Claude Code binary with their own Claude subscription".
• Usage Policy: no coordinating "malicious activity across multiple accounts to avoid detection or circumvent product guardrails", and no circumventing "a ban through the use of a different account".
• Authentication docs: "To stay signed in to multiple accounts at once, such as work and personal accounts, give each account its own configuration directory."
• GitHub Actions docs: a CLAUDE_CODE_OAUTH_TOKEN generated with claude setup-token works on Pro, Max, Team and Enterprise plans. For a secret shared across repositories the docs advise an API key instead, "since an OAuth token is tied to the subscription of the person who ran claude setup-token."
• No term in these sources limits how many subscriptions one person may hold, and none names usage-limit or rate-limit circumvention.

Operator checklist

• Every account in the roster belongs to you and is paid by you. Never share, lend or pool accounts or credentials: Consumer Terms §2.
• Keep Team and Enterprise seats out of the roster; the tool refuses them (MaxTierAdmission.cs), and they fall under the Commercial Terms.
• Use only the unmodified claude binary for model requests, with no proxy and no third-party harness on subscription credentials: the legal page allows signing in to "the unmodified Claude Code binary".
• Sign in through Claude Code's own login flow (claude auth login), never by pasting tokens taken from somewhere else: sign-in "must complete through Anthropic's own flow" (legal page).
• Switch by hand. Do not add automatic rotation at usage limits: limits "assume ordinary, individual usage" (legal page); see the human-click bullet under Posture.
• Keep the tool's own User-Agent and never imitate Claude Code's: Anthropic has banned tools that spoofed the Claude Code client (public report).
• Read usage only when asked, inside the existing budget: the usage endpoint is undocumented; see the read-budget bullet under Posture.
• CI: one claude setup-token token per account, generated by the account owner, stored as a repository or organization secret that only the owner's workflows can use. Re-read the GitHub Actions docs before you share a secret across repositories: the token "is tied to the subscription of the person who ran claude setup-token".
• Use Claude only from a supported country, and avoid VPN exits that change your region: account creation from an unsupported location is a listed suspension reason.
• Re-check the sources table whenever Anthropic announces a terms, limits or enforcement change, and at least once a quarter, then update the "Last reviewed" date above.

How this tool compares

Behavior	Does it?	Where
Model inference outside claude	No	Posture, first bullet
Proxy between claude and Anthropic	No	Posture, first bullet
Background timer for reads, refreshes or switches	No	Posture, switch and read bullets; QuotaRefresh.cs
Refreshes a parked token	Only during a requested read: when its recorded expiry has passed, or once when the usage endpoint answers 401, followed by one retried read. Done under the tool's own write gate; a switch holds Claude Code's own refresh lock	QuotaRefresh.cs, OAuthRefreshLock.cs
Usage reads	Bounded: at most once a minute per account, only on request	Posture, read bullet; RefreshBudget.cs
User-Agent	Its own, on every request	AnthropicEndpoints.cs
OAuth client_id for parked refreshes	Claude Code's public one	Posture; AnthropicEndpoints.cs
CI tokens	Only on a click: the unmodified claude setup-token makes the token, you sign in on Anthropic's page and paste the code, and the token goes from the CLI's output to gh secret set in memory, never to disk, a log, or the page	Rotating the CI token; ClaudeCliSetupTokenRunner.cs

Two points are gray:

• The usage endpoint is undocumented. No Anthropic statement allows or forbids reading it.
• The legal page says "developers may not collect, store, or intermediate Claude.ai credentials or session tokens". The tool stores and moves your own tokens between your own folders, and refreshes parked ones with Claude Code's client_id. That sentence is addressed to "developers" building products that offer Claude sign-in to their users, which this tool does not do, but the page does not address a person managing their own credentials.

Known enforcement (public reports)

• Anthropic confirmed in January 2026 that it banned use of third-party tools that spoofed the Claude Code client: https://x.com/trq212/status/2009689809875591565.
• Account creation from an unsupported location is a listed reason for suspension: safeguards warnings and appeals.
• Unconfirmed anecdote, not confirmed by Anthropic: community reports link bans to automatic multi-account rotation that refreshes tokens in the background and polls usage for idle accounts: https://www.reddit.com/r/ClaudeCode/comments/1uouvo8/ (2026-07-06).

Claude Desktop is out of scope

Last checked: 2026-10-06.

The tool switches the Claude Code CLI only. A switch leaves the Claude Desktop app, including its Code tab, on whatever account it last signed in to. To change Desktop's account, sign out and back in from Desktop itself.

What Desktop does:

• It has its own login, not the CLI's. The authentication docs say "Claude Desktop and cloud sessions do not call apiKeyHelper or read these environment variables: they use OAuth" (authentication). Desktop and the CLI share settings, MCP servers and CLAUDE.md, and the docs list no shared login (desktop). A request to share the CLI's login with Desktop was closed as not planned (anthropics/claude-code#62206).
• Its Code tab counts against Desktop's account. Desktop's usage ring shows "your plan usage for the period", and "plan usage is shared across all your Claude Code surfaces" (desktop).
• Anthropic documents one account switch only. An individual account and a Team or Enterprise account on the same email can be switched from the initials menu (log in to your Claude account). Desktop has no documented counterpart to the CLI's per-account configuration directory.

Community tools take two approaches:

• Swapping Desktop's files. These tools save and restore Desktop's stored login while it is closed: its cookie file, which holds the claude.ai web session, and the sign-in token entries in its config.json. Some also decrypt those tokens to read usage on a timer, or switch accounts automatically.
• One data folder per account. These tools start the official app with Chromium's --user-data-dir launch option, so each account signs in and refreshes inside its own folder and the tool never touches a credential. Anthropic does not document the option for Desktop. An open report in its tracker says a sign-in started in a second instance completes in the first one (anthropics/claude-code#98549).

Why the tool does neither:

• Swapping files parks more than the CLI does. Moving the CLI's credential files is already gray (see How this tool compares). Desktop's cookie is a full claude.ai web session, the "Claude.ai credentials or session tokens" the legal page names, and its storage layout is undocumented and can change with any Desktop update.
• A data folder per account rests on an undocumented launch option. It keeps credentials inside the official app, so it is the lower-risk route, but it has no Anthropic statement behind it and has open sign-in bugs. It stays out of scope until Anthropic documents it.
• No public report ties a ban to either approach, and no Anthropic source allows either. The absence of reports is weak evidence: these tools have few users.

Install

Download the release from https://github.com/melodic-software/claude-code-account-rotation/releases/latest. The assets are claude-code-account-rotation-win-x64.exe (the Windows leader), claude-code-account-rotation-linux-x64 (the follower the WSL side runs), claude-code-account-rotation-follower-log (the wrapper the leader starts in its place), SHA256SUMS, and config.template.json (the template the executable embeds).

Check each binary against the digest SHA256SUMS lists for it. A release download does not keep the executable bit, so on Linux run chmod +x on claude-code-account-rotation-linux-x64 and claude-code-account-rotation-follower-log before the first run. Place the executable on PATH, or make a shortcut to it, and run it once.

A missing config.json is written on that first run from the embedded template. The written file fills its paths from the user profile. It sits in the app data directory unless --config pointed somewhere else. That directory is %LOCALAPPDATA%\claude-code-account-rotation on Windows, and claude-code-account-rotation under the local application data directory (~/.local/share unless XDG_DATA_HOME is set) on Linux and macOS.

The process prints Dashboard: and the bound URL. The default port is 48211. --port 0 asks the operating system for a free port for that launch. Without --open no browser opens: open the printed URL, and paste line 2 of instance.url when the page asks for the instance token.

With --open, the dashboard opens in the default browser already signed in. If an instance is already running, --open opens that instance's dashboard and exits. Otherwise, on Windows, --open starts the leader as a separate process with no window, waits up to 30 seconds for it to listen, opens its dashboard, and exits. If it does not come up, --open exits non-zero and says why; run the same command without --open to watch it start in the console. On Linux and macOS, --open with no instance running starts the process in the foreground as usual and opens its own dashboard once it is listening.

The leader --open starts has its own hidden console, so closing an ordinary terminal window does not stop it. A launcher running inside a job object that kills its processes on close still takes the leader down with it; some IDE terminals and Win32-OpenSSH sessions do that. The Start-menu shortcut and the logon task are not affected.

Stop the tool with the Stop button in the dashboard header. It stops the WSL follower first and then the leader, and lets a rotation in flight finish. While a switch or import is in progress on either side, it refuses, says why, and both keep running. That refusal is the only thing that blocks the stop: any other follower answer, or none within 10 s, lets the leader stop, and the page shows what the follower said. With more than one side in peers[] it refuses before stopping anything; stop each process with POST /api/shutdown instead. The page cannot start the tool again: run claude-code-account-rotation --open, or on Windows use the Start-menu shortcut.

When the leader starts, it brings up every side that has peers[].launch set. It leaves a side that is on its own version alone. It starts a side that is not running. A side on another version is stopped and started again. It moves no account. If a side cannot be brought up, the leader logs why and keeps running, and the side reads offline or incompatible. Start WSL side on the page tries again. Upgrading a release says how this lets either side be installed first.

Scripts use routes. POST /api/shutdown stops only the process it is sent to, on either side, which is what an upgrade that replaces one side's binary wants. POST /api/stop on the leader is the Stop button: send it in place of /api/shutdown below to stop both sides. Both answer 409 while a switch or import is in progress:

$instance = Get-Content "$env:LOCALAPPDATA\claude-code-account-rotation\instance.url"
Invoke-RestMethod -Method Post -Uri "$($instance[0])/api/shutdown" `
  -Headers @{ Authorization = "Bearer $($instance[1])"; 'X-Claude-Code-Account-Rotation' = '1' }

Stop-Process -Name claude-code-account-rotation or Task Manager is a last resort: a hard kill skips that drain, and a token refresh cut off mid-write can leave an account's rotated credentials stranded.

If a card says it is not on the roster, click Adopt. Adopt is only offered for a Max account that is already logged in on this machine. Otherwise use Add an account, then Login on the card that needs a login. profilesRoot is the only hand edit, and the tool has to be restarted after it.

Rate-limit stop hook

When a session stops on a usage limit, Claude Code waits for the reset. The optional hook hooks/rate-limit-stop.sh tells the running dashboard, which reads the live account's usage once (at most once a minute per account). When a side's account is at 100% of its 5-hour or 7-day window, or of a model's weekly window such as Fable's, the dashboard shows a "switch now" prompt naming the first usable account in its order whose usage was read in the last 30 minutes. An account at its Fable weekly limit is never named, because the tool cannot know which model a session will run; you can still switch to it by hand. When every usable account's figures are older than that, the prompt names none: it says which account is unverified and how old its figures are, and offers Refresh usage. Nothing switches until you click it.

Install it on the side the leader runs on. The follower has no hook route, and the hook reads only the account the leader's side is logged in as. For an account the other side holds, Refresh usage asks that side to read it with its own access token, and its card also shows that side's statusline figures.

1. Save hooks/rate-limit-stop.sh from the release tag you run, and on Linux run chmod +x on it. It needs bash and curl. On Windows, Git Bash is required: without it Claude Code runs hooks in PowerShell, where bash can resolve to WSL's bash.exe and the hook does nothing.

2. Add the hook to ~/.claude/settings.json, with the path where you saved the script (Claude Code 2.1.78 or later):

   {
     "hooks": {
       "StopFailure": [
         {
           "matcher": "rate_limit",
           "hooks": [{ "type": "command", "command": "bash /path/to/rate-limit-stop.sh", "timeout": 10 }]
         }
       ]
     }
   }

The script reads instance.url from the default app data directory and exits quietly when the app is not running. It posts to POST /api/hooks/rate-limit with the headers POST /api/shutdown takes. It answers 202 when a read started, or 409 with one of these refusal values: NoLiveAccount (no account is logged in on this side), RateLimited (the account was read inside the last minute, or the usage endpoint's lockout is still running), or RefreshInProgress (a refresh is already running).

Reading the dashboard from scripts

GET /api/dashboard, sent with Authorization: Bearer and the token on the second line of instance.url, returns more than the page needs. Only these fields are supported for scripts; a change to any of them is a breaking change in the CHANGELOG. Everything else may change without notice.

• accounts[], in the dashboard's order: grouped usable, then model-limited, then limited, then exhausted, then unread, then paused. Within a group, accounts sort by nextResetAt (the weekly reset for a usable account), earliest first, with an undated one after every dated one, then by e-mail.
• accounts[].email.
• accounts[].standing: usable, model-limited (a model's weekly window, such as Fable's, is at 100% and the 5-hour and 7-day are not; nextResetAt is that window's reset and accounts[].limitedModel names it), limited (the 5-hour window is at 100% and the 7-day is not; nextResetAt is the 5-hour reset), exhausted (the 7-day window is at 100%), unread, or paused.
• accounts[].nextResetAt: when the account frees up (ISO 8601), or null when there is no wait or none that can be dated.
• accounts[].usage.limits[] where kind is session (5-hour) or weekly_all (7-day): percent (null when unknown or the window has reset since the read) and resetsAt.
• accounts[].isLive: true for the account this side is logged in as.
• accounts[].slot: where the account's pair is when the store is shared with another side: held-here, held-elsewhere, parked, in-transit, or never-logged-in; null when the store is not shared.

Which side holds a held-elsewhere account comes from GET /api/sides, sent the same way. It returns one entry per configured side (an empty list when none is). Supported fields:

• [].side: the side's name, for example wsl.
• [].online: whether that side answered.
• [].liveAccount: the account that side is logged in as, or null when it holds none. It is also null when the side did not answer, and that side may then still hold an account.

Rotating the CI token

A CLAUDE_CODE_OAUTH_TOKEN secret authenticates Claude Code in GitHub Actions. Each lane can have its own: one account per repository or organization secret. A card that backs a secret shows a CI · <repository> badge (hover it for the secret name and dates). The badge warns in the last 30 days of the token's one year and says when it has expired. CI draws on that account's 5-hour and 7-day limits alongside your interactive sessions on it.

Prerequisite: the GitHub CLI (gh) on PATH, signed in (gh auth login) as someone who may write that secret. The tool checks this before a token is made.

1. Pick the card with the most 7-day headroom.
2. Open its ··· menu, then Generate CI token. Enter the secret name, then the repository (owner/name) or the organization and who may read it (private, all, or selected repositories). Choose Start.
3. Anthropic's sign-in page opens in the account's mapped browser profile. Sign in as that account, then paste the code it shows into the card and choose Submit code.
4. The tool hands the token to gh secret set on its standard input and marks the account on its card. Marking it clears the badge from the account that backed the same secret before.

The token never leaves memory: it is not shown, logged, written to disk, or passed as an argument. A failure (a rejected code, gh refusing the write, or a CLI release whose screen the tool cannot read) ends the session without storing anything, and the message gives the manual commands: claude setup-token, then gh secret set <name> --repo <owner/name> (or --org <org>).

claude setup-token draws its screen only when its input is a terminal, so the tool runs it under one: a pseudoconsole (ConPTY, Windows 10 1809 or later) on Windows, and a POSIX pseudo-terminal on Linux. On macOS the action refuses and you run the commands by hand. The terminal is 1,000 columns wide, so nothing on it wraps. The tool reads only two things from that screen: the sign-in URL, which must be whole (with its code_challenge and state), and the token, matched by its sk-ant-oat01- prefix. Exactly one token must appear, standing alone on its row. CI runs the real CLI under that host on both Windows and Linux, so a release that changes either one fails a check.

To mark an account by hand instead (for a token made outside the tool, or when the tool set the secret but could not update the roster), open Edit and set "CI token generated on". Optionally also set "CI secret name" and "CI secret in" (owner/repository, or an organization), then Save. The same write is PATCH /api/accounts/{email} with {"ciTokenGeneratedOn":"yyyy-MM-dd","ciTokenSecret":{"name":"...","repository":"owner/name"}} (or "organization" in place of "repository"), sent with the headers POST /api/shutdown takes. A marker that names no secret replaces the other markers that name none. Clearing the date clears the secret too.

Build

Requires the .NET SDK pinned in global.json.

dotnet restore --locked-mode
dotnet build -c Release --no-restore
dotnet test -c Release --no-build

Releasing

A fix pull request that should ship dates its CHANGELOG heading: ## [x.y.z] - YYYY-MM-DD. Ask the operator before dating a heading. When that change reaches main, the release workflow tags the merge commit vx.y.z and publishes the release in the same run. A push to main whose top dated heading already has a published release publishes nothing. Pushing a v* tag by hand still publishes from that tag.

Upgrading from account-rotation

The tool was named account-rotation until 2026-09-07. The executable, the User-Agent product token, and the per-user app data directory carry the new name, and the tool does not migrate the old directory. Stop the old executable, then move the directory once, contents unchanged:

• Windows: %LOCALAPPDATA%\account-rotation to %LOCALAPPDATA%\claude-code-account-rotation.
• Linux and macOS: account-rotation under the local application data directory (~/.local/share unless XDG_DATA_HOME is set) to claude-code-account-rotation beside it.

Parked profiles under ~/.claude-profiles and Claude Code's own ~/.claude are not affected.

Upgrading a release

This is how you move from one tagged release to the next. It is separate from the rename above. Releases from v1.0.0 on read the files the previous release wrote. There is no migrator and no schema bump. Do not edit config.json, roster.json, or state/live-owner.json, and do not copy a template over an existing config.

The app does not call the GitHub API, and the dashboard has no "update available" line. Compare claude-code-account-rotation --version with https://github.com/melodic-software/claude-code-account-rotation/releases/latest.

Install the two sides in either order. Neither install has to wait for the other, and neither has to stop the other side.

1. Download claude-code-account-rotation-win-x64.exe, claude-code-account-rotation-linux-x64, claude-code-account-rotation-follower-log, and SHA256SUMS. Check each binary and the wrapper against the digest that file lists for it. Replace nothing until they match. Place claude-code-account-rotation-follower-log in the same directory as the Linux binary.
2. Windows side. Stop the leader with POST /api/shutdown, replace the .exe, and start the leader. Send Authorization: Bearer with the token on the second line of the leader's instance.url, and the same X-Claude-Code-Account-Rotation: 1 header as the other dashboard writes. A 409 means a switch or import is in flight, so the leader was left running: try again once it finishes. If the logon task from melodic-software/provisioning#552 is installed, disable it before the stop and enable it after the start. This repository does not name that task.
3. WSL side. Replace the Linux binary and the wrapper while the follower runs. Rename a new file over each one, as chezmoi does. Do not copy over the running binary: Linux refuses that with "Text file busy". Do not stop the follower.

What happens after each order:

• Windows first. The new leader finds the follower on the old version. It stops the follower with that side's own /api/shutdown and starts it again. The Linux binary installed at that moment is still the old one, so the old build starts again, but now it knows the new leader's version. When the WSL install lands, the follower sees the new build is the leader's version. Within about 15 seconds, once no import is in flight, it stops with exit code 75, and the leader starts the new build. Hand-offs are refused between the two installs, because the versions differ.
• WSL first. The follower keeps running the old build, which still matches the old leader, so hand-offs keep working. It knows the leader runs the old version, so it does not stop for the new build. When the new leader starts, it finds the follower on the old version, stops it, and starts the new build.

Either way, a side is stopped only through its own /api/shutdown, which refuses while a switch or import is in flight. A refused stop leaves that side running on its old version, and the page shows it as incompatible. Start WSL side, or POST /api/sides/wsl/start on the leader, tries again: it stops and starts a side on another version, and starts one that is not running. The leader runs one of these passes at a time per side, so its startup, the button, and a follower's exit cannot overlap. Only exit code 75 makes the leader start the side again. A crash, or a stop you sent, is left for you.

Upgrading onto this release from an earlier one, Windows first: the old follower does not stop for a new build by itself, so click Start WSL side once after both installs. Installing WSL first needs no click.

When both sides are done, claude-code-account-rotation --version prints the same version on each, and the page shows the WSL side online.

Uninstall

There is no --uninstall switch, no uninstall script, and no uninstall route. Remove the tool by hand, in this order.

1. If the logon task from melodic-software/provisioning#552 is installed, disable it. This repository does not name that task.
2. Start the leader and the follower if either is not running. Startup finishes or unwinds an open switch or import journal, and it restores a recovery file. Do this even when you already stopped the processes: a journal left behind is what the next start uses to finish a move, and deleting it first leaves a parked pair with nothing to put it back.
3. While they are running, the page must show no blocking banner, the same rule as an upgrade. No switch or import may be in flight.
4. On each side, look in recovery/. A *.credentials.json outside stale/ can be the only working lineage: the token endpoint has already invalidated the refresh token in the profile folder. Restart that side, or refresh the card, so the file is restored. Do not continue while such a file remains, even when no card says credentials stranded in recovery.
5. Stop the leader and the follower with POST /api/shutdown. Send Authorization: Bearer with the token on the second line of that side's instance.url, and the same X-Claude-Code-Account-Rotation: 1 header as the other dashboard writes. A 409 means a switch or import is still in flight, so the process was left running.
6. Read appDataDirectory, profilesRoot, liveConfigDirectory, and stateFilePath from config.json. Read the leader's file, and the follower's when peers[].launch.configPath names one, and take each side's appDataDirectory from its own file.
7. Delete each side's app data directory. Also delete config.json when --config or peers[].launch.configPath put that file outside the app data directory.
8. Delete the executables you installed.

config.json sits in the app data directory unless --config pointed somewhere else. That directory is %LOCALAPPDATA%\claude-code-account-rotation on Windows, and claude-code-account-rotation under the local application data directory (~/.local/share unless XDG_DATA_HOME is set) on Linux and macOS. Those four keys name the directories: delete each appDataDirectory, and leave profilesRoot, liveConfigDirectory, and stateFilePath. A file that moved them is the authority, not these defaults.

Leave the profiles root. That tree holds the parked pairs, holder.json, superseded.json, and .transit. Leave the live directory and Claude Code's state file. Parked profiles under ~/.claude-profiles and Claude Code's own ~/.claude are the defaults those keys name.

What disappears with the app data directory: the roster alias, notes, pause, and browser mapping; the quota cache; the computed queue; and quarantined families.

What survives: the live Claude Code login, and the parked pairs.

Remove on a card is the explicit per-account logout. Uninstall never calls it, and never runs claude auth logout against the live directory.

After a later install, parked folders show as not on the roster, and Adopt is offered only for the live account.

License

MIT, see LICENSE.