3 ms·
I love how everyone is trying to solve the same problems, and how different the solutions are. I made this little Dockerfile and script that lets me run Claude
by binwiederhier 7mo ago
I love how everyone is trying to solve the same problems, and how different the solutions are.
I made this little Dockerfile and script that lets me run Claude in a Docker container. It only has access to the workspace that I'm in, as well as the GitHub and JIRA CLI tool. It can do whatever it wants in the workspace (it's in git and backed up), so I can run it with --dangerously-skip-permissions. It works well for me. I bet there are better ways, and I bet it's not as safe as it could be. I'd love to learn about other ways that people do this.
https://github.com/binwiederhier/sandclaude https://github.com/binwiederhier/sandclaude
- mehdibl 7mo agoLovely you discovered devcontainers.
- schipperai 7mo agoNice! Docker is a solid approach. Actual isolation is the ultimate protection. nah and sandclaude are complementary - container handles OS boundaries, and nah adds the semantic layer. git push --force is risky even inside the container
- bryanlarsen 7mo ago> as well as the GitHub and JIRA CLI tool That's a pretty powerful escape hatch. Even just running with read-only keys, that likely has access to a lot of sensitive data....
- schipperai 7mo ago100% - lots of commands with server side effects out there
- binwiederhier 7mo agoMy co-worker figured out a way to run the GitHub CLI with read-only keys restricted to specific repos. I need to do that still.
- pragmatick 7mo agoI thought "I know that username". I love ntfy, thanks for developing it.
- binwiederhier 7mo agoI love that you love it. That's why I do it. :-)
- schipperai 7mo agohey - ntfy is very cool! kudos and thanks :)
- binwiederhier 7mo agoThanks.
- bryanlarsen 7mo agoHave you isolated the container from the Internet?
- binwiederhier 7mo agoI don't want to isolate the container from the Internet :-) I understand that this is not the safest possible way (exfiltrating is still possible, but I mostly work on open source anyway, so that's not an issue), but I think the convenience wins here. That said, if you have suggestions that are not super inconvenient, please let me know. My main goal with this was to make sure it cannot go wild on my own system.
- niobe 7mo agoBut is anthropic trying to solve it? The current permissions solution is unbelievably poor for a product with this much traction.
- schipperai 7mo agoThey are releasing auto-mode soon. But that won't improve the underlying permission system, rather, it'll just delegate decisions to Claude. That's better than --dangerously-skip-permissions, but not great for those that want granular controls and are sensitive to the extra tokens spent.
- kate23_human 7mo agoDocker isolation is a good baseline, but the tricky part is usually the boundary between “safe filesystem access” and tools that can indirectly access secrets (git configs, environment variables, credential helpers, etc). Even read-only access to a repo can leak quite a bit depending on what’s in the workspace. I’ve seen some teams run tools inside containers but mount a filtered workspace rather than the full project directory to reduce exposure.
- schipperai 7mo agogreat callout - tool call can have side-effects outside your box. So unless you run a sandbox with no internet access, you aren't ever 100% safe. nah does guard some of this - reading .env or ~/.aws/credentials gets flagged, and Write/Edit content is inspected for secrets before it leaves the tool. Docker + filtered mounts + something like nah on top is a solid layered approach that is still practical.
- nicwolff 7mo agoYeah, same – mine gives Claude a proxy to the host's Docker socket that disallows mounting anything outside the dev dirs or starting a --privileged container, so it can run tests. https://github.com/nicwolff/claude-container/ https://github.com/nicwolff/claude-container/