[binwiederhier]

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

[schipperai]

Nice! 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

[kate23_human]

Docker 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]

great 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]

Yeah, 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/

[bryanlarsen]

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

[binwiederhier]

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

[schipperai]

100% - lots of commands with server side effects out there

[pragmatick]

I thought "I know that username". I love ntfy, thanks for developing it.

[binwiederhier]

I love that you love it. That's why I do it. :-)

[niobe]

But is anthropic trying to solve it? The current permissions solution is unbelievably poor for a product with this much traction.

[schipperai]

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

[mehdibl]

Lovely you discovered devcontainers.

[bryanlarsen]

Have you isolated the container from the Internet?

[binwiederhier]

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

[schipperai]

hey - ntfy is very cool! kudos and thanks :)

[binwiederhier]

Thanks.