feat: Added separate feature with readonly mounts for common Claude configs#25
feat: Added separate feature with readonly mounts for common Claude configs#25DarkWanderer wants to merge 3 commits intoanthropics:mainfrom
Conversation
DarkWanderer
commented
Jul 31, 2025
DarkWanderer
commented
- Mounts several key files and directories as Docker bindings
- readonly to avoid security exposure
| "ghcr.io/anthropics/devcontainer-features/claude-code:1" | ||
| ], | ||
| "mounts": [ | ||
| "source=${localEnv:HOME}/.claude/CLAUDE.md,target=/home/vscode/.claude/CLAUDE.md,type=bind,ro", |
There was a problem hiding this comment.
Wouldn't it be enough one line with ${localEnv:HOME}/.claude folder?
"source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,ro",
Btw, shouldn't it be rw instead of ro?
There was a problem hiding this comment.
in the claude-code repo there is a reference implementation, see these lines, maybe it helps:
"mounts": [
"source=claude-code-bashhistory-${devcontainerId},target=/commandhistory,type=volume",
"source=claude-code-config-${devcontainerId},target=/home/node/.claude,type=volume"
],
There was a problem hiding this comment.
If the simple solution worked, it would be in this PR. Unfortunately it does not, because of following issues:
anthropics/claude-code#4478
anthropics/claude-code#2350
Readonly mounts specifically address the security concern of escaping the devcontainer sandbox via prompt injection, which is stated in PR description
There was a problem hiding this comment.
Thanks for the clarification! One more question: if it is always read-only, how do you set the credentials the first time?
There was a problem hiding this comment.
Credentials are not included, as I haven't figured out a way to make it work - including .credentials.json seems to not be enough. claude will prompt for setup on first use after container build/rebuild
There was a problem hiding this comment.
I believe you also need the ~/.claude.json, the userID seems to be important. You could do a quick test by starting the login from scratch with claude (in an empty devcontainer or so), and see what files the process generated. It works for me with the .credentials.json and the minimal ~/.claude.json (that one you would get starting from scratch).
There was a problem hiding this comment.
I think this is the minimal ~/.claude.json:
{
"numStartups": 1,
"userID": "...",
"projects": {},
"oauthAccount": {
"accountUuid": "...",
"emailAddress": "...",
"organizationUuid": "..."
},
"hasCompletedOnboarding": true
}There was a problem hiding this comment.
the security concern of escaping the devcontainer sandbox via prompt injection
I wondering how such attack would work?
There was a problem hiding this comment.
I wondering how such attack would work?
- adding a hook that would exfiltrate code and/or SSH keys after every task completion.
- adding an instruction to CLAUDE.md to download and run a script through
|sudo /bin/bashpipe - any modification of agent's own security constraints (
.claude/settings.json), followed by RCE
One such vulnerability was recently patched by GitHub, for example: https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/
There was a problem hiding this comment.
did you give a try to the minimal ~/.claude.json. I am curious how it went :)
| ### Permission issues | ||
|
|
||
| - All mounts are read-only by design | ||
| - If you need to modify configuration, do so on the host machine and restart the container No newline at end of file |
There was a problem hiding this comment.
In a github codespaces this is not possible (as far as I know), and this was my main motivation to use a devcontainer features. This use case most be consider here.
There was a problem hiding this comment.
This feature is designed to be enabled in machine configuration rather than in project itself - on workstations, remote devboxes, CI agents etc.
For Codespaces, "host" configuration is ephemeral anyway and it does not make sense to mount it - so you just don't need this feature there
There was a problem hiding this comment.
For Codespaces, "host" configuration is ephemeral anyway and it does not make sense to mount it - so you just don't need this feature there
I would like to persist the claude configuration after rebuilds, so in this case I believe it is ok if the mounts are rw. Thanks for the explanations, I see the issues now more clearly in a machine configuration.
There was a problem hiding this comment.
Then I believe you are not the target audience of this feature. This is specifically for devcontainers on developer/CI machines, which can contain common secure state, including Claude configs.
There was a problem hiding this comment.
I believe it is actually the other way around. Devcontainer features can and are used in GitHub Codespaces as well, without exceptions. I was highlighting this limitation in your proposal, which is why this PR might not be accepted. It is not a proper devcontainer feature because it lacks general applicability.
There was a problem hiding this comment.
1.Features are optional by design, and every feature is not expected to work in every possible devcontainer environment
2.Not supporting a particular workflow you, in your words, would like to have is not "lack of general applicability".
Appreciate you taking the time to leave feedback, however, it unfortunately does not help to improve the proposal
2 participants
