I use devcontainers in all the projects I use claude code on. [1] With it you can have claude running inside a container with just the project's code in write access and also mount a test folder with just read permissions, or do the opposite. You can even have both devcontainers and run them at the same time.
It seems to scratch that same itch for me for some reason. The constant inherent danger, the different skill levels of raiders mixing together and yet people have fun and lose their stuff and it's a blast to play.
I think there are two big takeaways that GitHub has the power to implement:
1) actions/cache could default to workflow-isolated caches and require opt-in to shared caches between workflows, forcing workflow writers to understand the risks when they want to take them. This is a relatively "traditional" CI system safety design and perhaps something of an oversight.
2) GitHub needs a stronger defense against fork "commit-washing" than a banner in the UI because the greatest risks are places where the UI isn't visible. Right now GitHub will allow you to check out commits from forks as if they are commits in the main repository. This is a part of how GitHub works, all forks are stored in essentially the same repo under the hood for storage and computation benefits. But it's also a key to too many exploits that `action: actions/checkout@someCommitHash` might come from any fork of `actions/checkout` not just the GitHub official repo and any use of `npm install github:microsoft/vscode#someCommitHash` might come from any fork of `microsoft/vscode`. If a developer follows those commit links into the GitHub UI there's a warning banner those commits are from a fork, but you don't see that in a workflow YAML today and npm has no warnings if it happens. Even though this is a deep part of how GitHub works under the hood, it probably shouldn't be allowed to be this visible from outside of GitHub's walls and more security tools should prevent it both internal to GitHub and external to it (with npm being sort of both in that npm's developers are under GitHub's roof, too).
If I'm understanding the issue correctly, an action with read-only repo access shouldn't really be able to write 10GB of cache data to poison the cache and run arbitrary code in other less-restricted actions.
The LLM prompt injection was an entry-point to run the code they needed, but it was still within an untrusted context where the authors had forseen that people would be able to run arbitrary code ("This ensures that even if a malicious user attempts prompt injection via issue content, Claude cannot modify repository code, create branches, or open PRs.")
It can have better defaults but that's about it. If LLM tells user the LLM needs more permission user will just add them as people that are affected by bugs like that traded autonomy and intelligence to AI
reply