Posted by shmulc 1 hour ago
That said, a few thoughts:
1. .claude/settings.local.json is meant to stay local. This is not a file you should check into source control. We automatically gitignore it when Claude creates the file, so in this case the files were manually created and checked in (docs: https://code.claude.com/docs/en/settings)
2. Permission rules are old hat. Everyone should be using auto mode instead. It is safer and also does not require manually maintaining finicky allow/deny lists. Auto mode is enabled by default and is included for free in all plans.
3. Regardless of what agent you use, you should have secret scanning enabled. GitHub and other source control hosts offer it. There are many threat models that it protects against and you should absolutely use it if you can. (see https://github.com/security/plans)
As it says:
> 5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice
Claude Code never should have prompted to always allow Bash(python:*) or Bash(node:*) — that’s clearly a bad idea, and Anthropic know that (given the references in the article!).
Of course, Bash(python a.py) still isn’t safe if you also allow Write(a.py), because you may as well allow Bash(python:*) at that point, and that’s often practically what people want (“I want to both make edits to the source and then run the test suite”). So maybe the whole permission system is broken to start with — and the actual answer is leaning more heavily on fine-grained sandboxing.
You also, as the article rightfully points out, run into permission fatigue and users blindly hitting allow.
I do still wish you could do more with hooks — outside of auto, I might want to allow a given command via a hook if Claude Code has read access to given file, but there’s no way to query if a given path allows/denies read/write.
1. After a command is blocked, run /permissions to retry and allow it going forward
2. More deeply configure the classifier itself: https://code.claude.com/docs/en/auto-mode-config
We are working on making these easier and more automated.
I frequently hit stop on and auto mode task to prevent it from completely flooding my context with some completely unrelated garbage.
Claude really should push away tasks that end up needing more exploration in worker contexts. That way the workers can maintain a sensible amount of context without pushing the main chat into the dumb region.
> "but we are looking into what we can do to prevent this"
I would presume that CC's auto-review of tool-call turns would already solve this >99% of the time, no? From my read, any harness-side deterministic solution here would be saving the user from themselves, which seems like a bad pattern. Somewhat dulling the scalpel in my mind.
If we've already crossed the bridge to being confident in a non-deterministic reviewer for auto-mode, then, I see no obvious reason as to why we couldn't have the proposed rules be generated by a model. If that were reality, then- all rules placed in settings.local could be secretless, with the confidence of whatever model we tell 'make sure the rule does not contain secret material, consider its destination as potentially public'.
[1] https://code.claude.com/docs/en/permissions#wildcard-pattern... AFAICT, CC will either save off a prefix+wildcard rule, or exact command. Sounds like the former is likely not the cause of the problem here.
1. We store any of your secrets we find in plaintext please don't commit them with `git add -A`, don't worry Claude will do this for you.
2. Just let us run arbitrary commands on your laptop, it's totally safe (for us)
3. Fuck you, it's not our problem
When knowledgeable people show up to address concerns on HN, that's good for all of us. We don't need you to like or agree with what they say, but we do need you to follow HN's guidelines.
Threads like this can easily turn into mob dynamics—it has happened before—and when they do, that's bad for all of us.
So pressing “Don’t Ask Again” by itself doesn’t expose passwords by itself. If you commit your local Claude settings and in those settings you have manually approved commands containing secrets directly in the command and then you publish the repo, that’s exposed.
If you post output from AI, please remember to edit before publishing
> Is it public?
>
> Search your GitHub organization for .claude/settings.local.json and .claude/settings.json. Each hit is a file anyone can read right now.
Or am I missing something
Even then, you might not want every developer in your company to have the password to the production SQL database...
This incident would have been caught in an open source harness. This one is closed source malware, and you don't know what Claude Code does internally to behave like this.
Yet another reason why you cannot trust a closed harness.
Same thing could/would happen with an open source harness.