feat: Added separate feature with readonly mounts for common Claude configs

[DarkWanderer]

• Mounts several key files and directories as Docker bindings
• readonly to avoid security exposure

[pablospe]

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?

[pablospe]

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"
],

here: https://github.com/anthropics/claude-code/blob/e499db6e9edd1a6e8085b0392e62cec005fe9049/.devcontainer/devcontainer.json#L43C1-L46C5

[DarkWanderer]

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

[pablospe]

Thanks for the clarification! One more question: if it is always read-only, how do you set the credentials the first time?

[DarkWanderer]

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

[pablospe]

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).

[pablospe]

I think this is the minimal ~/.claude.json:

{
  "numStartups": 1,
  "userID": "...",
  "projects": {},
  "oauthAccount": {
    "accountUuid": "...",
    "emailAddress": "...",
    "organizationUuid": "..."
  },
  "hasCompletedOnboarding": true
}

[pablospe]

the security concern of escaping the devcontainer sandbox via prompt injection

I wondering how such attack would work?

[DarkWanderer]

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/bash pipe
• 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/

[pablospe]

did you give a try to the minimal ~/.claude.json. I am curious how it went :)

[pablospe]

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.

[DarkWanderer]

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

[pablospe]

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.

[DarkWanderer]

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.

[pablospe]

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.

[DarkWanderer]

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