45 MB of Claude Code Sessions You Don't See

A documented user investigation from late April 2026 found that on one Windows machine, only 69 of 715 Claude Code sessions (roughly 10%) were visible in the desktop application's sidebar, while the remaining 646 sessions (totaling about 48 MB) remained intact on disk but inaccessible through the app. This occurs because Anthropic introduced weekly rate limits on Pro and Max plans in August 2025, prompting power users to maintain multiple accounts and rotate them when hitting caps, but the desktop application's storage layer was designed for only one account at a time, storing each account's sessions in separate directories while only displaying the active account's sessions.

A documented user investigation posted in late April 2026 reported, for one Windows machine, the following two numbers: 715 Claude Code sessions on disk, and 69 sessions visible in the Claude Code desktop application's sidebar. Roughly ten percent. The other six hundred and forty-six sessions, totalling about 48 megabytes of local .json files, were on the disk, were intact, and were entirely absent from the only program that can natively open them. I want to take that ten-percent number seriously rather than file it under "user error" or "edge case," because the structural reason it happens is the same reason it will happen to anyone with more than one Anthropic account, and there are now a fair number of people in that category. Anthropic introduced weekly rate limits on its Pro and Max plans on August 28, 2025, which means the response of any sufficiently committed Claude Code user is, eventually, to maintain more than one account and rotate when one of them hits its cap. This is not an exotic workflow. It is the normal response of a tool's power users to a quota policy. The desktop application was not built around it. The current weekly-limit structure is documented across Anthropic's pricing pages and a year of TechCrunch / Northflank / Portkey coverage. The $200/month Max plan offers, by Anthropic's own published guidance, somewhere in the 240–480 hours of Sonnet and 24–40 hours of Opus per week. The $100 plan is roughly half that. The Pro plan is well below either. For someone using Claude Code as a daily driver on multiple substantial projects, the cap is not theoretical — power users hit it within days of each weekly reset window. The standard response, visible across half a dozen GitHub-issue threads and a year of community posts, is to maintain two or three accounts and switch when the active one runs out. Anthropic does not document this, does not condone this, and does not make it convenient — but the alternative is that the tool stops working partway through the week, and the calculus, for paying customers who depend on it, is straightforward. The desktop application's storage layer was designed for one account at a time. The collision between that design and the rotation pattern is the source of every symptom that follows. Anthropic does not document on-disk session paths in the official Claude Desktop documentation. The CLI version's ~/.claude/ directory layout is documented; the desktop app's is not. The path users have reverse-engineered, and that the user investigation cited above located at line 771 of the bundled .vite/build/index.js as the constant claude-code-sessions , is: ~/Library/Application Support/Claude/claude-code-sessions/<accountId /<orgId /local .json %APPDATA%\Claude\claude-code-sessions\<accountId \<orgId \local .json Each session is one JSON file. Each account gets its own <accountId directory. Each organisation under that account gets its own <orgId subdirectory. On a single user's Windows machine, the count of accountId directories was six — the user expected four, but two old accounts were still on disk and forgotten, including the largest one 44 megabytes, 330 sessions, dormant since early April . The desktop application reads from one of those six directories at any given time — the active account's. The other five are inert, on the same disk, in the same parent folder, holding sessions in the same JSON format, and not displayed. There is no UI affordance to view them, no setting to merge them, no documented way to migrate a session out of one and into another. Sessions do not become invisible because they are corrupted or deleted. They become invisible because the application does not look in their folder. Documentation gaps in a developer tool are usually accompanied by a GitHub paper trail, and Claude Code's is unusually long for a product still under heavy development. Issue 26452, opened February 18, 2026, by a Max subscriber on macOS reporting that sessions disappeared after logout and reappeared only on the disk. Bug label, Open status, dozens of community comments, no MEMBER/OWNER replies as of late April. Issue 48511, opened April 15, 2026: same symptom, fresh report, again open with no engineering response. Issue 29373 — closed — is where the community located the path constant in the bundled JavaScript, by literally diffing build artefacts. Issue 48362 reports that Microsoft Store / MSIX builds break entirely, because the atomic-rename step from local <sid .json.tmp to local <sid .json fails with EXDEV inside the MSIX virtual file system, treating source and target as different devices. Issue 18645 — closed as a feature request — is where one user hypothesises that version 2.1.9 introduced a stricter check that prevents copying sessions between machines, on the basis of regression testing rather than any documented Anthropic announcement. Issue 54428, opened April 28, 2026, reports that on Claude Desktop 1.4758.0 for some macOS users, an entirely different storage format has begun rolling out: ~/Library/Application Support/Claude/vm bundles/claudevm.bundle/ , containing rootfs.img , sessiondata.img , and efivars.fd . A disk image, not a directory of JSONs. The combination paints a clear picture. The session-storage layer is in active churn. Users are filing precise, well-instrumented bug reports and, on the most active thread, getting no MEMBER or OWNER reply at all. The community has been building its own discovery and migration tooling for at least three months, against a target that is currently moving. Three storage formats in twelve months is the pattern. The first format, used through 2025, was local-agent-mode-sessions/ . It was renamed to claude-code-sessions/ in early 2026 — issue 29373, closed without comment, is the only public trace of the rename. Some user-built tools still parse for the old name as a fallback. The second format, the current claude-code-sessions/ layout, is the one all the user reverse-engineering above maps. The third format, the in-flight VM-bundle architecture from issue 54428, replaces the directory of JSON files with a single mounted disk image. Anything that reads local .json will stop working when the bundle migration completes. There are good reasons a developer tool might consolidate session storage into a sandboxed image — Anthropic's published positioning around agent isolation suggests one motive — but the consequence for users running custom tooling is that any tool which targets the on-disk format has, by construction, a short life. A migration script written against the current paths becomes a dead asset the moment the next storage format reaches general availability. Users who have built workflows around the JSON files are pre-emptively building the next workaround for the next migration. The same product family ships in two flavours, and only one of them has this problem. The CLI version of Claude Code stores sessions in ~/.claude/projects/<slug / , keyed by project rather than by account. Switching accounts on the CLI updates .credentials.json and nothing else; the project's session history is shared across whatever account is currently authenticated. The CLI's storage layout survives the multi-account rotation pattern without any of the desktop application's pathology — sessions remain where they were, accessible to any account that opens the same project folder. The desktop application's choice to scope sessions by <accountId /<orgId / is the structural source of the invisible-sessions symptom. If the storage path were project-keyed instead, a session opened under one account would still be visible to the next account on the same project. The desktop app's design treats the account as the primary key for the data; the rotation workflow treats the project as the primary key. The difference is invisible until you look at where the JSON files end up. This is not a bug that will be fixed by adding a "show sessions from other accounts" toggle to the sidebar. It is a schema choice that has not been reconciled with how the tool gets used. Chasing the on-disk format is, on the evidence of the last twelve months, a losing game. Three storage formats in twelve months, no documentation, no engineering response on the open issues, a fourth format already shipping. Any user-built migration tool is a stopgap with a measurable shelf life. The right architectural answer is to stop relying on the application's storage for state that needs to survive a format change. The pattern that does survive is per-project handoff files. At the end of each long Claude Code session, the agent writes a short markdown file into the project's own repository, in something like .claude/handoffs/<date <session-id .md . The file is short and structured: the session's goal in one sentence; what was actually done, with file names; what didn't work — the most valuable section, the hypotheses checked and discarded, with reasons; the current state of the work; one specific next step; and a small read-only check-list of things the next session should verify before resuming. The next session opens in the same project folder, reads the most recent handoff, and picks up the thread, regardless of which account is logged in, regardless of which storage format Anthropic shipped this morning. The handoff file lives in your repo. Anthropic cannot reformat it. Switching machines does not lose it. Switching accounts does not hide it. The session-storage layer Anthropic owns is allowed to churn — it will keep churning, on the evidence — and the project state that the developer actually cares about lives somewhere churn cannot reach. This is not a Claude-specific architectural pattern. It is the standard advice for any tool you do not own: the persistent state of work needs to live in storage you control. A migration tool that reads someone else's storage is, by definition, a temporary measure. A handoff file written by the agent into your own repo is the permanent measure. The 90% invisible-sessions number is not a bug in Claude Code. It is the predictable consequence of a per-account storage schema meeting a multi-account usage pattern that exists because of weekly rate limits the storage schema was not designed around. The weekly limits are a real product constraint. The multi-account rotation is a rational user response. The per-account <accountId /<orgId / directory layout is a rational design decision. Each piece is locally sensible; the combination produces a state where most of one user's session history is unreachable from the application that wrote it. The fix the user community is converging on is not to chase the storage layer, because the storage layer is not stable enough to chase. The fix is to keep the project state outside the application entirely. That move has the additional property of making the user's work portable across versions, across machines, across accounts, and across the storage formats Anthropic has not yet shipped. The session files Anthropic owns are going to get reformatted. The handoff file in your repo is not. That is the difference, and it is the part the ten-percent number is really showing — that the visible part of any external tool's storage is the part you can lose, and the only state worth depending on is the state you wrote yourself.