How to Persist Cline Storage and History in Dev Containers

According to the Stack Overflow 2025 Developer Survey, Docker adoption has reached 71 percent among professional developers, confirming that containerized environments are now standard for modern software engineering Stack Overflow 2025 Developer Survey. This widespread shift highlights the need for reproducible, isolated development environments. However, using these ephemeral containers for autonomous agentic workflows creates a major friction point. Every time a developer rebuilds their Dev Container, they lose their entire Cline task history and extension configuration.

This data loss happens because of how VS Code structures its extension architecture in remote containers. When you use a Dev Container, VS Code runs in a client-server configuration. The user interface runs locally on your host machine, while the backend editor engine runs as the VS Code Server inside the Docker container. Extensions like Cline are installed and executed directly on the containerized server, not on your local host. Consequently, all extension state, databases, and logs are written to the container's internal storage path.

For Cline, which is identified in the VS Code Marketplace by the extension ID saoudrizwan.claude-dev, this configuration directory is located in the VS Code Server user data directory Cline GitHub Repository. Specifically, Cline stores its databases, settings, and task checkpoints under the globalStorage directory. If this folder is not mapped to persistent storage, it behaves as temporary container file space. When you update your Dockerfile or edit your devcontainer.json configuration, Docker destroys the existing container instance and creates a fresh one. This process discards the entire ephemeral file system, wiping out all previous agent context.

To prevent this, you must map the directory where Cline writes its data to a persistent storage location. Developers have tried using simple host bind mounts or pushing code repositories to cloud buckets to persist files. However, keeping the internal state of the agent intact requires mounting the exact system paths used by VS Code Server.

The primary method to persist Cline data across container life cycles is configuring the mounts array in your devcontainer.json file VS Code Dev Containers Documentation. The mounts property allows you to define Docker volumes or bind mounts that mount host paths or Docker volumes to specific targets inside the container. This configuration ensures that even when the container is destroyed and rebuilt, the underlying volume containing Cline's history remains intact.

The exact path you must target depends on the user running the VS Code Server process inside the container. If your container runs as a non-root user, which is the recommended practice for security, the default username is typically vscode. If your container runs as the administrative root user, the target path changes accordingly.

For a container running as the vscode user, you can configure the mounts block like this:

"mounts": [
  "source=cline-global-storage,target=/home/vscode/.vscode-server/data/User/globalStorage/saoudrizwan.claude-dev,type=volume"
]

If your development environment is configured to run as root, you must adjust the target path to point to the root user's home folder:

"mounts": [
  "source=cline-global-storage,target=/root/.vscode-server/data/User/globalStorage/saoudrizwan.claude-dev,type=volume"
]

In these configurations, the source parameter defines the name of the Docker volume. Docker automatically creates this volume on your host machine if it does not already exist. The type parameter is set to volume, which is highly recommended over a bind mount. Named Docker volumes provide superior read and write performance on macOS and Windows hosts because they avoid the file system translation overhead associated with mapping direct paths from the host OS.

While persisting the globalStorage directory keeps your task history safe, it introduces a new operational challenge. Cline creates detailed task checkpoints during its autonomous operations Cline GitHub Repository. These checkpoints contain complete snapshots of files at various stages of a task, allowing you to review changes or roll back files if the agent makes an error. Over time, these checkpoint databases and file snapshots grow in size. It is common for the saoudrizwan.claude-dev directory to grow to several gigabytes after a few days of heavy development.

If you leave this directory unchecked, it can fill your local drive. You should monitor the size of your Docker volumes to prevent performance degradation. You can run the following command on your host machine to check overall Docker disk usage:

docker system df

To inspect the specific metadata and disk location of the Cline persistent volume, run:

docker volume inspect cline-global-storage

If you need to free up disk space, you must manage these checkpoints. While you can run a general cleanup command to delete unused volumes, you must exercise caution:

docker volume prune

Running the prune command deletes all volumes that are not currently associated with a running container. If you run this command while your Dev Container is stopped, Docker will delete your cline-global-storage volume, erasing your entire task history. To avoid this, always make sure your container is running before executing a volume prune, or delete checkpoint files manually from within the VS Code editor interface.

Configuring a local Docker volume solves the storage problem for a single developer on a single workstation. However, it does not address the collaboration needs of modern software teams. If you need to share the agent's output with colleagues, review code changes together, or maintain an audit trail of what the agent changed, local container volumes are insufficient.

Some teams attempt to address this by bind-mounting their project folders to local host directories, using Amazon S3 buckets for file storage, or syncing folders with consumer cloud storage services like Google Drive. These methods present significant integration challenges. They do not track file version history automatically, lack built-in search capabilities over the agent's output, and make it difficult for team members to inspect and run the code without manual setup.

A shared workspace platform like Fastio offers a much stronger approach for human-agent collaboration. Fastio provides shared workspaces where agents and humans collaborate on the same files, shares, and workflows. Instead of locking your agent's work inside a local container volume, you can connect Cline to a Fastio workspace. This configuration allows the agent to read and write files directly in a cloud environment accessible to the entire team.

Fastio supports this workflow by exposing a consolidated Model Context Protocol toolset via Streamable HTTP at /mcp and legacy SSE at /sse, which is documented at the Fastio developer documentation. Connecting Cline to this remote endpoint gives it direct access to the workspace. Once you enable Intelligence Mode on a workspace, all files uploaded by Cline are automatically indexed for RAG chat and semantic search. Human team members can search across documents using Hybrid Search Metadata Views, which combines exact full-text matching with semantic retrieval to find specific passages, database schema files, or code documentation.

Furthermore, Fastio tracks every change using per-file version history. If Cline overwrites a file or introduces a bug, you can restore previous versions with a single click. When Cline completes a task, it can transfer organization ownership to a human manager using a claim link. The human reviewer then takes control of the billing and administrative settings. Fastio operates on a credit-based pricing model with paid plans starting at $29/mo for Starter, $99/mo for Business, and $299/mo for Growth Fastio Pricing Page. Every organization starts with a 14-day free trial that requires a credit card to activate, ensuring a reliable environment for your development workflows Fastio Product Features.

Collaborate with Cline in a persistent cloud workspace

Provide your AI agents with a shared file system that features automated indexing, semantic search, and instant handoff tools. Start your 14-day free trial to build a secure workspace.

Start 14-Day Trial

After updating your devcontainer.json file, you must verify that the volume mount is working correctly. First, save your devcontainer.json file. Open the VS Code Command Palette by pressing F1, and run the Dev Containers: Rebuild Container command. This action stops the current container, creates the new cline-global-storage volume, and mounts it to the target path.

Once the container is running, open the Cline interface and start a test task. For example, ask Cline to run a simple command or create a temporary file. This step ensures that Cline writes initial task log data to the globalStorage directory. After the task completes, run the Dev Containers: Rebuild Container command a second time. Once the editor reloads, open the Cline panel and check the history. If your previous test task is visible in the task history list, your volume mount is configured correctly.

If your task history is empty, you are likely facing a permission issue. When Docker creates a named volume, it sometimes initializes the directory with root ownership. If your container runs as the vscode user, the VS Code Server process will not have the permissions required to write files to the mounted directory. This causes Cline to fail silently when trying to save task logs.

You can resolve this permission conflict by adding a command to your devcontainer.json file to adjust file ownership. You can use the postCreateCommand property to run a shell script when the container is built:

"postCreateCommand": "sudo chown -R vscode:vscode /home/vscode/.vscode-server/data/User/globalStorage/saoudrizwan.claude-dev"

This command runs automatically after the container starts, changing the directory ownership to the vscode user and allowing Cline to write to its storage path without errors.