This post is targeted devcontainer users not running the containers as root!
"remoteUser": "root", # Not for you!
In the end, this is basically a post about mounting folders and ensuring the right folder permissions - when not running with root permissions or as the root user.
You probably have a setup looking something like this:
devcontainer.json
{
"name": "Customer-Name - Dev machine - Debian",
"dockerComposeFile": "docker-compose.yml",
"service": "dev",
"workspaceFolder": "/xyz",
"remoteUser": "container-user", #This is the way!
"mounts": [
"source=claude-${localWorkspaceFolderBasename},target=/home/container-user/.claude,type=volume",
"source=continue-${localWorkspaceFolderBasename},target=/home/container-user/.continue,type=volume"
],
"postCreateCommand": "bash ${containerWorkspaceFolder}/.devcontainer/debian/post-container-install.sh",
The Problem: Root-Owned Named Volumes
When you run a container as a non-root user (like container-user), you immediately run into a distinct permission trap—especially on macOS hosts.
When Docker creates named volumes (like the ones for .claude and .continue), it defaults to creating them as the root user. If your container-user tries to write configuration files or save chat history to these directories, they will be hit with a Permission denied error.
The Solution: The Post-Install Script
To fix this, we use the postCreateCommand to trigger a script that corrects the permissions from inside the container after the volumes are mounted.
Your post-container-install.sh script should look like this:
#!/usr/bin/env bash
# Fix permissions on mounted volumes since they are owned by root when created by the container, but we want them to be owned by the container user.
sudo chown -R container-user:container-user /home/container-user/.claude \
/home/container-user/.continue 2>/dev/null || true
echo "Devcontainer setup complete!"
Why this works
The sudo chown command explicitly transfers ownership of the mounted volumes from root back to your non-root user. Because these are Docker named volumes rather than direct host bind mounts, the permission change persists across container rebuilds. This keeps your AI assistant extensions functioning correctly, ensuring your configuration and history remain intact and writable.
No more logging into Claude between builds!
Enjoy :)
Top comments (0)