Live data from Hacker News

Show HN: A context-aware permission guard for Claude Code

github.com

41–50 of 109 posts

Re: Show HN: A context-aware permission guard for Claude Code

#42
It helps but a LLM could still code a destructive command (like inlined python -c scripts) you can't parse by rules and regex, or a gatekeeper LLM be able to understand its implication reliably. My solution is sandbox + git, where the .git folder is write protected in the sandbox as well as any outside files being r/o too.

My personal anecdata is that both cases when Claude destroyed work it was data inside the project being worked on, and not matching any of the generic rules. Both could have been prevented by keeping git clean, which I didn't.

Re: Show HN: A context-aware permission guard for Claude Code

#44

How do people install stuff like this? So many tools these days use `npm install` or `pip install`. I certainly have npm and pip installed but they're sandboxed to specific projects using a tool like devbox, nix-devshell, docker or vagrant (in order of age). And they'll be wildly different versions. To be pedantic `pip` is available globally but it throws the sensible `error: externally-managed-environment` I'm sure…

tbh copy paste the github link and ask an agent for a nix package. you may have to do some prompt engineering but usually done in less than 10 ish mins

Re: Show HN: A context-aware permission guard for Claude Code

#45

As binwiederhier mentioned, we're all solving the same problems in different ways. There are now enough AI sandboxing projects (including mine: sandvault and clodpod) that I started a list: https://github.com/webcoyote/awesome-AI-sandbox

Nice list!

As you say lots of effort going into this problem at the moment. We launch soon with grith.ai ~ a different take on the problem.

Re: Show HN: A context-aware permission guard for Claude Code

#46

How do people install stuff like this? So many tools these days use `npm install` or `pip install`. I certainly have npm and pip installed but they're sandboxed to specific projects using a tool like devbox, nix-devshell, docker or vagrant (in order of age). And they'll be wildly different versions. To be pedantic `pip` is available globally but it throws the sensible `error: externally-managed-environment` I'm sure…

I tend to use things like pyenv or nvm; they keep python and node versions in environments local to your user, rather than the system.

`pip install x` then installs inside your pyenv and gives you a tool available in your shell

Re: Show HN: A context-aware permission guard for Claude Code

#49

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 thought "I know that username". I love ntfy, thanks for developing it.

Re: Show HN: A context-aware permission guard for Claude Code

#50
post #42

It helps but a LLM could still code a destructive command (like inlined python -c scripts) you can't parse by rules and regex, or a gatekeeper LLM be able to understand its implication reliably. My solution is sandbox + git, where the .git folder is write protected in the sandbox as well as any outside files being r/o too. My personal anecdata is that both cases when Claude destroyed work it was data inside the proje…

nah does classify python -c as lang_exec = ask, and the optional LLM layer sees the actual code, but it's not bulletproof. Keeping a clean working tree is probably the single best defense regardless of tooling.
Post reply on HN