Where Claude Code desktop sessions go when you switch accounts

I run several Claude accounts, because weekly limits exist and when one account hits them I switch to the next. Every switch rebuilds the session list in the Claude Code desktop app, and the previous account's sessions disappear from the window, though not from the disk. In April this machine held about 710 sessions in six account folders, roughly 49 MB of history, and the app showed 69 of them. This post covers where the sessions physically live, the four scripts I wrote to find and restore them, what I deliberately did not automate, and why my real long-term answer is a handoff file in my own repository. Revised in September 2026 with corrections and with what happened to those sessions since.

Where the sessions live

On macOS the desktop app keeps each session in ~/Library/Application Support/Claude/claude-code-sessions/<accountId>/<orgId>/local_<sid>.json. On Windows the same structure sits under %APPDATA%\Claude\claude-code-sessions\. None of this is documented. In April the desktop docs said that each conversation is a session with its own chat history, project folder and code changes, and nothing about where it is stored.

The folder name comes out of the app's bundled JavaScript: in .vite/build/index.js, line 771 holds const $6t="claude-code-sessions". The reporter of issue #29373 had found the same line, and the folder was there on my machine. The app loads sessions only from the active account's folder, so every other account's sessions stay intact on disk and invisible in the window. A quick script over the folders gave this:

[372ac280…] sessions=4    size=2K     last=2026-04-13  → a test account
[4d1f33a2…] sessions=330  size=44M    last=2026-04-08  → the main archive (abandoned)
[a4ea2866…] sessions=83   size=4.5M   last=2026-04-10  → archive
[a9e945b6…] sessions=83   size=252K   last=2026-04-26  → recent parallel
[be2110e2…] sessions=69   size=203K   last=2026-04-29  → ACTIVE RIGHT NOW
[c53acc1e…] sessions=141  size=244K   last=2026-04-26  → recent parallel

Six accounts, not the four I was sure about. I had simply forgotten two old ones, and the most forgotten of them, 4d1f33a2, held the main archive: 44 MB, 330 sessions, five months of work.

Correction, September 2026. The April text said 715 sessions and 48 MB. The table above adds up to 710 sessions and about 49 MB, so those are the numbers used here.

Nobody official was answering

I counted at least ten GitHub issues about this, seven of them active on 30 April. #48511, opened on 15 April, is literally "session history lost when switching accounts". #26452, open since February, had 40 comments and not one from an account marked as a member, owner or collaborator of the repository. I checked every comment by hand: forty complaints into silence.

Update, September 2026. #48511 was closed as "not planned" on 24 May after a period of inactivity. People kept commenting after the closure, and between June and September three community scripts for switching accounts or restoring sessions were linked in the thread. #26452 is still open, now with 53 comments, and still none from a member of the repository.

Four scripts to find and restore sessions

The toolkit is four cross-platform Python scripts in my public claude-code-config repository, under skills/operational/desktop-sessions-discovery/:

• sessions_registry.py, the main entry point. It reads every session from every account and builds one self-contained HTML dashboard with search and sorting, then opens it in the browser. Each card shows the title, date, number of turns, project, size and a selectable session id. The active account is highlighted, and sessions that were already restored are marked from a migration journal, ~/.claude/desktop-migrations.jsonl, with a filter to hide them. It reads both the current claude-code-sessions/ and the older local-agent-mode-sessions/, renamed in February 2026.
• sessions_inventory.py, a text report grouped by account, with a summary of projects that appear in more than one account.
• sessions_find.py, substring search over titles and working directories, with filters by account and time window.
• sessions_restore.py, which copies one session into the active account, verifies the copy byte for byte, writes a journal entry and never deletes the original. After a restart of the desktop app the session is in the window.

In practice I tell Claude "show me all sessions on this machine for migration", the skill picks up the phrase, and the dashboard opens. I scroll to, say, a 392-step session from the abandoned archive, copy its id, tell Claude "restore these three", restart the app, and the sessions are there. On a Mac there is a bonus: mdfind -onlyin ~/Library/Application\ Support/Claude/ "colour checker" searches the text inside the session files through Spotlight. Windows has no equivalent, and sessions_find.py does the same job by walking the files in about half a second.

Update, September 2026. The April text described a Restore button on each card. I had already removed it the day before publication, in version 3.6.4, because all it did was copy a command to the clipboard while looking like it did more. Each card now has a session id you triple-click and copy. The same release fixed lookup: a short query such as "26" used to match the middle of unrelated ids, and now only the start of an id matches.

To install it, I would not copy anything by hand. Open Claude Code in any folder and give it the repository:

Take https://github.com/AnastasiyaW/claude-code-config, find the
desktop-sessions-discovery skill in skills/operational/, install it into
~/.claude/skills/, then run sessions_registry.py and show me the dashboard.

Claude clones the repository, reads SKILL.md to learn how the skill is used, copies it and runs it. That is the normal way skills work: you hand the agent a toolkit and it learns it the way a person reads a README.

What I deliberately did not do

• No bulk merge of all 710 sessions into the active account. A sidebar with 700 entries is unreadable, especially with about fifty empty scheduled runs such as a morning digest among them. A bulk copy is also exactly what a stricter validity check would reject. One session for one task works better.
• No automatic migration on startup. A tool nailed to today's storage format turns into a pumpkin the moment the format moves. Search and selective restore are safer than automation.
• No symlinks between account folders. My global rules forbid them: they break on the first path change, create invisible dependencies and breed strange bugs six months later. Copy only.
• Originals are never deleted. After a restore, the source file stays in its account folder as the backup, in case a future check rejects the copy or the restore has to be repeated.

The tool has an expiry date

The storage has already changed shape once: local-agent-mode-sessions/ became claude-code-sessions/ in February (#29373). A second change was showing. In one user's report on macOS (#54428, 28 April), Claude Desktop 1.4758.0 was writing a virtual-machine bundle, ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/, with rootfs.img (10 GB), sessiondata.img and efivars.fd, while the same log shows sessions still loading from claude-code-sessions. A disk image is not JSON. If sessions move into it, copying local_*.json files will stop working.

Two more cracks were already visible in April. Microsoft Store installs are broken separately (#48362): inside the MSIX sandbox the atomic rename of local_<sid>.json.tmp to local_<sid>.json fails with EXDEV, because the virtual file system sees source and target as different devices, so sessions are not saved at all. And in #18645 a CLI user reported that sessions copied between machines, which resumed on version 2.1.5, stopped being recognised on 2.1.9, and guessed that a check now blocks sessions not created on the current machine. That is the CLI, not the desktop app, so it is a warning sign rather than proof. Migration between accounts on one machine still worked.

Update, September 2026. The MSIX issue was closed as "not planned" in June. Its title recommends switching to the ordinary Win32 installer, but comments from 24 April and 18 May say that route is gone: the download button now ships an MSIX package behind what looks like a Win32 installer. #54428 was closed as "not planned" in June too. Of the eight issues I cited in April, only one was closed as completed: #53717, sessions whose content went missing after an auto-update on Windows. It was closed in August without a comment, and a week later a user asked for it to be reopened.

Why a handoff is my real strategy

The migration tool solves today's problem, and I did not expect it to survive a release or two. Anthropic can move sessions into SQLite, an encrypted disk image or the cloud; each time, home-made restore tools break. So the long-term strategy is different: a handoff after every important session.

Memory and CLAUDE.md hold the project's facts and rules. They do not answer "what was I doing in the last session, which hypotheses did I check, which dead ends did I hit". At the end of each long session Claude writes .claude/handoffs/YYYY-MM-DD_HH-MM_<session-id>.md into the project with six fields:

• the goal of the session, in one sentence;
• what was done, concretely: files, tests, numbers;
• what did not work, with reasons, which is the most valuable part;
• the current state: working, broken, blocked;
• one next step;
• a read-only checklist for the next session.

One file per session, never overwritten, with an append-only INDEX.md next to them. A new session reads about 1,500 tokens of handoff instead of 50K tokens of history, and does not repeat the previous session's dead ends.

The two tools solve different problems. Restoration reaches into someone else's storage and depends on it. A handoff writes the state into mine, at the moment I still hold the context in my head. The old session can be lost completely, and the new one still knows the goal, the work, the failures and the next step. The coordination side of this, for several sessions working at once, is in the post about many Claudes in one repository and in mclaude.

The storage layout decides one more thing. The desktop app splits sessions by <accountId>/<orgId>/, so a handoff written next to a desktop session is invisible to a session in another account. The CLI keeps everything in ~/.claude/projects/<slug>/ regardless of account: switch accounts and only .credentials.json changes. That is the quiet reason my work keeps moving to the CLI.

Update, September 2026. The handoff protocol has grown since April. Handoffs now go into a subfolder per project, .claude/handoffs/<project-slug>/, so a busy project cannot crowd out the one you came back to. A hook rejects a handoff without a closure audit: is the request complete, what was verified, which related tasks were checked, where unfinished ones are tracked, and why work stops here. And a new session no longer opens by asking "resume or start fresh": the user's current request comes first, and a relevant handoff is read quietly. The current rule is rules/session-handoff.md.

What happened to those sessions

Added in September 2026, measured on the same machine on 23 September.

	April 2026	September 2026
account folders in claude-code-sessions	6	4
session files	710	522
size	about 49 MB	about 10 MB
oldest session in the live folder	not recorded	6 June 2026

By 6 June the whole session store had been copied into a recovery backup on another drive: 1,003 files, 49.9 MB, the same six account folders. Nothing in the live folder today is older than that: not one of the 522 sessions in it was created before 6 June. So the app cannot show a single session from the April table. Their files are in the backup, not in any folder the app reads.

What came through is what lived in my own project folders. The handoff from 12 May in my tile-memory project is still in that project and opens today, with its goal, what failed and the next step (the project itself is here). That is the argument of this post, tested by accident. One honest footnote: that handoff was never committed, only its index was, so it survived because the folder was copied. By my own rule it should have been in git.

Sources

• #48511: history lost when switching accounts; closed as not planned in May 2026.
• #26452: sessions gone after logout or restart; open, no reply from the repository's members as of September 2026.
• #48362: MSIX EXDEV.
• #18645: session export and import between machines; the 2.1.9 hypothesis.
• #54428: VM bundle on macOS 1.4758.0.
• #29373: the rename to claude-code-sessions.
• #53717: content missing after an update on Windows.
• #54723: sessions disappearing mid-conversation on macOS; its reporter later closed it as user-side, an auto-archive preference combined with a sidebar filtered to active sessions.
• Claude Code desktop docs (no storage paths) and the .claude directory docs (the CLI side is documented).
• claude-sync: multi-machine sync for the CLI through R2.
• The toolkit: desktop-sessions-discovery. Handoff background: principles/18-multi-session-coordination.md and alternatives/session-handoff.md in the same repository.