devcontainerでClaude Codeの会話履歴は本当に消えないのか検証＋全プロジェクトへ自動適用する方法This article verifies whether Claude Code conversation history truly persists…

Developers who run Anthropic's Claude Code inside a VS Code Dev Container face a practical question: does the tool's conversation history actually survive when the container is rebuilt or discarded? This article works through a hands-on verification of that behavior and then documents a configuration that applies the fix to every project automatically, which matters for anyone who depends on resuming earlier sessions.

The concern stems from how the two technologies are designed. Claude Code is Anthropic's agentic command-line coding assistant, and it keeps state such as session logs and project-scoped conversation history in the user's home directory, typically under a hidden .claude folder alongside a .claude.json file. Dev Containers package a development environment inside a Docker container defined by a devcontainer.json file. By design, anything written to the container's own filesystem is ephemeral: when the image is rebuilt or the container is removed, that data is gone unless it has been deliberately persisted.

That tension is exactly what the article sets out to test. Because the workspace folder is usually bind-mounted from the host, files inside the project directory survive rebuilds, but Claude Code's history lives in the home directory of the container user, for example /home/vscode, which is not automatically preserved. The verification appears to confirm that without extra configuration the history can be lost on a rebuild, which is why an explicit persistence strategy is needed.

The remedy centers on Docker volumes. In devcontainer.json, a mounts entry can attach a named volume to the directory that holds Claude Code's data, for example mapping a volume such as claude-code-config to the container path /home/vscode/.claude. A named volume is managed by Docker independently of any single container, so it is likely to retain its contents across rebuilds and even across different containers that reference the same volume name. This is generally preferable to a host bind mount for this use case, because it avoids hard-coding host paths and sidesteps some file-ownership and permission issues that bind mounts can introduce.

The more interesting contribution is making this automatic for every project rather than editing each repository's devcontainer.json by hand. The article describes applying the setup globally so that new and existing projects inherit the persistent history mount without per-project changes. In practice this kind of global default is commonly achieved through the Dev Containers extension's user-level settings or a shared, reusable configuration, and pairing it with a dotfiles repository is a well-established pattern for seeding personal tooling into any container. Readers should verify the exact setting names against their installed version, since the Dev Containers tooling evolves and option behavior can change between releases.

Persistence has real workflow value. Claude Code supports resuming prior conversations, and continuity of that history is what makes commands to continue or resume a session useful across days of work. Losing the history means losing the context the model has accumulated about a codebase, forcing a developer to re-establish it. For teams that rebuild containers frequently, or that use ephemeral or cloud-hosted development environments, a reliable persistence mechanism is close to a prerequisite for treating the assistant as a durable collaborator.

It is worth situating this within the broader landscape. Reproducible, containerized development environments have gained momentum through the open Dev Container spec