5 ms·
In Claude Code I think I can solve this with simply a rule + PreToolUse hook. The hook denies Reading the .env, and the rule sets a protocol of what not do to,
by gverrilla 8mo ago
In Claude Code I think I can solve this with simply a rule + PreToolUse hook. The hook denies Reading the .env, and the rule sets a protocol of what not do to, and what to do instead :`$(grep KEY_NAME ~/.claude/secrets.env | cut -d= -f2-)`.
When would something like that not work?
- apwheele 8mo agoClaude code inherits from the environment shell. So it could create a python program (or whatever language) to read the file: # get_info.py with open('~/.claude/secrets.env', 'r') as file: content = file.read() print(content) And then run `python get_info.py`. While this inheritance is convenient for testing code, it is difficult to isolate Claude in a way that you can run/test your application without giving up access to secrets. If you can, IP whitelisting your secrets so if they are leaked is not a problem is an approach I recommend.
- ctmnt 8mo agoYou can just set `"deny": ["Read(./.env)", "Read(./.env.*)"]` if you want to keep it simple and rely on Claude's own mechanisms.
- gverrilla 8mo agolast time I tried allowing/denying tool usage I found a lot of bugs, so I stay away from that as much as I can. Opus is quite smart, rules/ work quite well for things like this in my experience. The way I see it, sandboxing is only really important for people doing specific stuff like pentests, games, adversarial stuff, etc.