Detailed Analysis
A recent community deep-dive maps out exactly where Claude sessions physically live on disk, filling a documentation gap that has apparently frustrated developers trying to understand Claude Code's persistence model. The core finding: Claude Code writes every session as a plaintext JSONL file under a `~/.claude/projects/<encoded-cwd>/` directory structure, with one folder created per working directory. This is a granular, filesystem-first approach to session storage rather than a centralized database, meaning the organization of stored conversations mirrors however a developer has structured their local project directories.
The more consequential discovery in this mapping effort concerns an inconsistency in how Claude Code keys its data. Transcripts are tied to the working directory, while auto-generated memory is tied to the git repository. This split has a concrete practical consequence for anyone using git worktrees, a common pattern for parallel feature development: three worktrees checked out from the same repo will produce three separate transcript folders, but they'll all funnel into a single shared memory folder. Developers relying on worktrees to isolate work streams could unexpectedly find memory context bleeding across otherwise-separated sessions — a subtle behavior that isn't obvious from Claude Code's documentation and could only be surfaced through direct filesystem inspection.
Perhaps the most notable finding involves data retention and what does or doesn't get cleaned up automatically. Claude Code's 30-day cleanup routine sweeps away transcripts, checkpoints, and caches, giving the impression that old session data is being tidily rotated out. However, the sweep explicitly does not touch `history.jsonl`, a file that accumulates every prompt a user has ever typed into the tool. This means that even as conversation transcripts age out and disappear, a complete historical log of user input persists indefinitely on disk. For users and organizations concerned about data hygiene, secrets accidentally pasted into prompts, or general privacy hardening, this is a meaningful and non-obvious distinction between what "cleanup" actually cleans up.
This kind of grassroots reverse-engineering reflects a broader pattern in how developers are engaging with agentic coding tools like Claude Code: because official documentation often lags behind rapidly shipping features, the community has taken on the role of building and maintaining infrastructure maps — session storage, instruction layering, memory hierarchies — through direct inspection rather than official reference. It also underscores a growing tension in AI coding assistants generally, where the convenience of persistent memory and context across sessions runs up against real questions about data lifecycle, storage sprawl, and what "deleting your history" actually means in practice. As agentic tools increasingly write, cache, and remember more about developer workflows, the mechanics of where that data lives and how long it survives become as operationally important as the AI capabilities themselves — and this kind of transparency, even when informal and crowd-corrected, fills a real need for teams evaluating these tools for security-sensitive or compliance-conscious environments.
Read original article →