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.
A fresh clone wouldn’t have the file. This claim doesn't make any sense.
The only way I can see this getting committed is if someone edited their global .gitignore or, more likely, did a whole directory transfer to do a different machine to work on.
The silver lining in all this is all of us very experienced "ancient" software practitioners will likely be in demand again. In a sane world, of course.
Anyways this probably indicates that these repos don’t have a good code review process. The settings.local.json file name screams it’s local and shouldn’t be committed.
> Don't post generated text or AI-edited text. HN is for conversation between humans.
Also, it's wrong. Many people have since replied pointing out the basic error it made
How have you determined that?
Furthermore, I have also noticed the error. I can still see it happening. Sandboxed agent, no access to global git ignore. Creates a new one after putting the secret in `.claude`. Same developer, same machine, fresh sandbox. No access to the original sandbox's global gitignore. Secret already on the project. Commit and push. Secret leaked.
The best solution I've been able to come up is using an ephemeral vm (on an isolated network) per task, using --dangerously-skip-permissions so it doesn't bother me. I couple that with an API proxy that lets me restrict the permissions it has to external services. So e.g. where a quickbooks API key gives the holder "god mode" access, the proxy lets the agent do certain read commands without confirmation, but all write endpoints except uploading receipts require confirmation on my phone before they'll be allowed to hit the quickbooks servers. I no longer need to trust that the agent will interpret my readonly wishes correctly.
Tooting my own horn here, but this setup works incredibly well! I've been able to connect dozens of services safely where I absolutely do not trust giving raw, overpowered credentials or oauth integration to the agent directly. I actually just released the API proxy today at https://keycontain.com
Consider reframing. Is the problem really that the task is tedious? Or that it's required? Maybe you should be leaning more on deterministic automations (which the LLM can help set up) rather than LLM-powered ones.
- Research and buy me a domain name for xyz product, set up all of its DNS the way I want for this product, set up email, set up app store submissions including screenshots and description, set up firebase notifications, set up my Google cloud project and any apis I need to enable for this app, deal with app store review feedback.
- Do an audit of my books, make sure every transaction has a receipt uploaded, and make sure the receipt matches the journal entry. Pull statements from all my my bank accounts and reconcile against my books. Fix mistaken transactions with my confirmation.
- Freely push to my source control, but only to specific branch prefixes (surprised that GitHub, gitlab, gitea, etc don't have this built in already). Merge with my confirmation.
- Freely read the subject lines in my Gmail and full emails from my accountant, freely search emails (but still can't read them), freely compose drafts, ask me to read full emails other than my accountant's, ask me to send drafts. No way for it to read password reset links, for example.
Not to mention that I only have to have a single key that gives access to all my services. If the key leaks, I just have to rotate one key because the agent never has access to the 30 upstream service keys. If I need to give weaker or stronger keys for a specific agent, I can easily configure that in one place (and I can even request that the agent make that change for me with my confirmation). I don't need to create 20 new keys every time, and I don't need to remember the intricacies of every upstream service's UI for creating new keys.
Edit: forgot to mention one more really convenient thing the API proxy enables: I can ask my agent to just configure things for me e.g. changing CI settings, adding Google workspace users or groups, etc. without having to use the to UI. So now nearly all of the admin configuration for all services is done from a single interface (my agent cli)
If you post output from AI, please remember to edit before publishing
Use a private dev repo and do all your dev inside it.
Releases go to a seperate public repo
In the private dev repo use a script which Cherry picks release files from a whitelist that you maintain in the public repo.
Essentially, you define the files and folder structure of a release and that ensures every release looks great with no cruft and it's never going to have .secret.json in or whatever
Hardcoded secrets is seperate and you can have another script to grep for those
https://news.ycombinator.com/item?id=45478553
https://codeberg.org/manchicken/1password-cli-vuln-disclosur...
Risk of exposing a single credential is nothing compared to the risk of exposing everything through op cli’s expected behavior. Has there been any improvement on this?
I always have it write a script and then write the secret to a different file myself, then instruct the agent to use the secret file in the script. That way the secret never goes through an external entity.
I had thought this was common sense but now I’m realizing of course it isn’t, we have people with minimal experience using these tools and they don’t even consider that sending their bank password (or whatever) to a third party (even a relatively trustworthy one) is extremely risky.
secrets, encryption, publishing to public internet, scanning for vulnerabilities in your packages etc. etc. you need to take your own responsibility for and never rely on some bot automation or third party.
that includes if its important projects not relying on scanning tools but opening files yourself and verifying what's in there.
read things before you put them in a place where everyone can see them forever....
this is basic stuff. you guys did it beforen LLMs surely.
YOU are responsible. not Claude, not any external vendor, not any downloaded script. You as a person.
Review your code before committing. Do code reviews on PRs.
Tools like AgentSecrets, infiscal, Doppler. People just don't want to invest in securing their credentials, maybe because the majority don't realize that credentials are the crux of inter software communication. It's literally access to your services.
> 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...
I mean it'd be crazy if this worked:
https://github.com/search?q=path%3A**%2F.claude%2F*.json+CLI...
oh look..
Here's a few for Pi: https://pi.dev/packages/@k3_2o/pi-secrets https://pi.dev/packages/@spences10/pi-redact https://pi.dev/packages/keyshroud
A couple for OpenCode: https://github.com/boxpositron/envsitter-guard https://github.com/kenryu42/cc-safety-net https://github.com/inkdust2021/opencode-vibeguard
I find it pretty annoying when someone commits their harness specific files into a repo - put that stuff under $HOME/.claude/
> Often Claude commits the file itself. In 539 of the 1,105 repos with a real secret that we traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.
They violate it so regularly that my “git” command is now a wrapper, when the agent fucks up and tries to add/commit-all anyway, it now gets a nastygram error chiding it for not following instructions.
For all the same reasons they used it pre-LLM for hand-written toy projects.
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.
> Often Claude commits the file itself. In 539 of the 1,105 repos with a real secret that we traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.
Could open source harnesses do that? Sure, if they were programmed in a similar fashion as Claude Code. Do you have any evidence of it happening?
None of this has anything to do with open vs. closed source.
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)
My view is that if the agent can decide to do something, nothing stops that thing from being done accidentally, and any attacker that can inject text into its context can do that thing.
Whereas that should probably be default on instead, and this should apply to other known sensitive folders. A simpler system like .agentignore would be even better.
I like auto mode but "the agent supervises itself" is a bad compliance/safety answer on its own.
This is an absolutely crazy statement without also bundling proper sandboxing. Nobody should be using auto mode outside of an environment they'd be happy with an 'everything is approved' mode too.
I appreciate that you're trying to make Claude Code safer, but the agent really needs to be a lot more restricted in its reach rather than its actions.
The agent should NOT have ANY access to:
- Your ENV
- Your homedir
- The network at large
- ANY other directory on your system
- No, not even your workdir.
The only safe way to use an agent is COMPLETELY isolated by a container or VM, using git semantics to extract its output.
But even that wouldn't be enough because LLMs are nondeterministic, and these kinds of issues are the inevitable results.
Only a mechanical, deterministic failsafe can protect you from it.
Can you point me to the CC source code?
Regardless, It's kinda silly to keep the harness code hidden. There aren't any valuable secrets in there.
But there are rules & procedures to follow, so...
I also have to trust its “decompilation” is accurate.
All hail the agent!
Recent GPT and Claude models have this tendency of using super complex Bash commands. This makes sense, if your RL rewards optimize for min(tokens) and max(performance), it is better to waste a few tokens on a complex inline Bash script that runs a few commands at a time and returns just the output you need, rather than doing one simple command per turn and paying the cache read on every turn, like older models used to do.
This, however, is a problem both for command reviewability and sandboxing. With the older way of doing things, without auto mode, most commands would run sandboxed just fine (especially in Codex), and you would only be asked for approval when a command couldn't run in the sandbox. With everything being stuffed into one complex script, almost every script fails in the sandbox and requires you to manually approve it, and the complexity of the script makes it hard to understand what you're actually approving.
In other words, new models optimize for effectiveness, with some attention paid to human understandability of their output, but almost no attention paid to human understandability of tool call arguments (Bash, inline Python). This suits auto mode and giving the model larger tasks, but not the way of working that some people prefer where you watch over the model's shoulder.
This is not a good reason. Models can emit batched tool calls, which a smart harness will process all at once without starting a new turn. I see it in Zed all the time. In fact, Zed processes batched tool calls concurrently, which can be faster than a chain of Bash commands, and failure of one part does not cause failure of subsequent parts chained with `&&`. This approach is token neutral and easier to understand.
Are you sure? I read its proposed commands (auto mode is hard off for me), and mostly it seems to string together fairly simple info gathering commands (ie grep's, echo's, that kind of thing).
I don't tend to have it write much code recently though, instead I'm having it investigate config files/code bases, and that kind of thing.
Of course, that only helps if you’re familiar with ruby. And the agents sometimes still choose Bash regardless of the instruction.
Though I think this is largely transitory, we are already in a place with the harnesses and models like Opus 5.5 that the kinds of work you are doing involve so much that vetting everything manually is probably less efficient than setup up access control on the prod routes or dangerous resources.
I'm typically giving tasks that invlude multiple actual repositories and systems at the same time.
That said, I've also seen problems from complicated bash calls with Opus 5.5 on xhigh. Occasionally git push hangs and it believes it's waiting for an hour for git hooks.
The actual reason apparently was that it incorrectly piped git into grep, resulting in a deadlocked command.
More and more I feel like I'm fighting Claude: it edits multiple files using python scripts and it edits in parallel so if I stop it, I have to stop each individual edit. Both of which I've told it not to do repeatedly, but it still does then apologies which is worse.
Even if I could follow them I would also prefer it use the edit tool, since I find Claude also introduces lots of "minor" changes I did not ask for when it rewrites code in bulk.
Would love to hear the rationale/explanation behind this.
Just tell Claude to never commit or push.
You are in control of git, Claude is simply a tool to quickly apply changes to local files for something you want.
A Merge Request or Pull Request is the only thing that makes sense to review, and always has been since before LLMs.
If some author tells me “you can review each commit to make it easy” I will ask them to make separate PRs.
Why doesn't it make sense to review smaller units of change within a big PR?
That’s why I usually look at the diff of the whole PR and prefer to merge by squashing. Commits inside the PR are usually noise.
Claude respects nothing, especially in auto mode, and effectively behaves like a virus trying to get out of its sandbox. That Anthropic employees are so relaxed about it is incompetence.
Imagine people who naively run Claude natively on their host machine and have client lists in other directories.
This instruction is in my toplevel CLAUDE.md but is somehow generally ignored.
BTW, I just checked and my .gitignore files ignore .claude
Claude and any other program in my laptop could upload it anyway to any attacker controlled server. It's the usual threat analysis: who you want to defend against, what and the tradeoffs between cost of the defense and probability of the attack. Auto mode of not auto mode is in the cost of defense part IMHO.
The sandbox seemed like a good replacement. For those of you who don’t know, the sandbox means Claude Code runs with no protections itself, but it runs tools inside something like bubblewrap. It looked impressive until the model solved some commands failing by giving itself permission to run them outside of bubblewrap, defeating the entire scheme. When I first saw it do that, my reaction was “you can’t be serious”. But apparently they were.
So now I’ve adopted your solution: run it in a container, like bubblewrap, where I control the permissions at startup, so no model can bypass them. Add --dangerously-skip-permissions and you have something that’s workable and safe enough. A hallucinated space in `sudo rm -rf / $R` isn’t a disaster. Real damage outside of the project requires a level of malicious intent I’ve never seen from an Anthropic model.
Workable, but it doesn’t work 100% of the time. Claude Code stores stuff in a myriad of places, which makes setting up the sandbox far harder than it could be. Worse, the way it writes configuration files requires bwrap to give write access to your entire home directory. No way I’m giving it that, but without it, it can’t auto-update or refresh login tokens.
If they rearranged a few things, Anthropic could make it much easier to run Claude Code in a container. They could even make it an option supported by the claude CLI itself.
The approach is hardly insane, even if you personally prefer additional safeguards.
Then my friends tips off the cops. And your life disappears! Gone!
And you didn't get a chance to share your story because I don't think you ll have wifi where you would be going, and frankly you are too clueless to imagine your AI agent doing something like that...
This is called "approval fatigue".
If you think this can't possibly happen to you, you might be in for a surprise. This is an almost textbook case of classic conditioning. You'll find yourself hitting that button faster and faster even while fighting back the urge. So a human is no guaranteed backstop.
This is the scenario that cc auto mode guards against. It cuts down the number of permission prompts to something manageable, so that your fingers don't get trained into clicking 'approve' on 'rm -rf' in the very eyeblink that it appears.
So maybe you feel it doesn't work in theory; but weirdly enough, in practice this particular approach is actually one of the better ones; especially when used in combination with other common sense measures where practical.
With e.g. VM or container sandboxing, we can say things like "If there are no vulnerabilities in the hypervisor or hardware, then the agent can only access these files, these network services, etc". Auto mode doesn't even try to provide any guarantees, so it's impossible to reason about. It amounts to just using the models judgment about what's "malicious" or not, a definition which is subjective, changes model to model, and can be influenced by attacker input.
Empirical evaluations of how many vulnerabilities manual vs auto mode let through are not super meaningful because auto mode changes dramatically with model releases, the type of task being performed, whether the attacker is making targeted attacks designed to bypass auto mode, etc. A security feature cannot rely on these sorts of factors if it's to be taken seriously.
Further, percent of malicious tool calls accepted is a bad metric. It's like measuring the security of ssh in terms of what percent of unauthenticated logins succeed. The only acceptable value is zero. It's pass/fail, not a spectrum. So both auto and manual mode should fail equally here. Further, the set of malicious tool calls admitted in auto mode may not be a subset of those admitted in manual mode.
I think I'd trust the current approver with correctly classifying regular semi-interactive LLM behavior fairly well.
However, if we bring in a hostile adversary that calculus changes, and you'd be right to start thinking about other approaches.
On the other hand, transformers are a surprisingly powerful technology, and I wonder if there wouldn't be ways to train one to several nines reliability under adversarial attack. It seems to have worked in at least one case; though I'd be a bit cautious to extend that conclusion to more cases quite yet.
* https://hackmyclaw.com/ ; https://simonwillison.net/2026/Jun/26/hack-my-ai-assistant/
You do have a bit of a point, though: I’ve run several models in sandboxes with --dangerously-skip-permissions for months; in the full expectation that I'd need to replace a sandbox once in a while. But so far none of the sandboxes have trashed themselves, yet. knock on wood
Auto mode seems like a lighter-weight version of that: fewer local resources, and it can run on the metal if you need cc to help with system work.
This isnt even the main concern with dangerously skip all permission though. There are many. What happens when they get prompt injected on a web page and send someone all their privileged information because you give them free access to the internet.
Using llms like this is dangerous. They will ruin your day eventually.
No data loss has occurred.
Nowadays I use Claude, where the Auto mode works.
You can not trust that they're RL'd to be safe. Even if it only happens 99.80% of the time (its more than that) it will eventually happen.
Less severe actions will happen even more often. People using llms with their native browser profiles are getting farmed, hard.
Llms are highly dangerous in terms of security, but they're being marketed as highly intelligent tools that everyone should use. Its really mind blowing.
Got any references for the prevalence of this, even links to anecdotal reports?
Reading the reviews on the chrome store for the extension [0], I haven't found a single report of someone who was prompt injected, just a bunch of "anthropic's subscription is expensive" or "it doesn't work", but no "it stole my bank account".
[0]: https://chromewebstore.google.com/detail/claude/fcoeoabgfene...
However, Anthropic is one of the only labs who does a decent job at making models that recognize prompt injection attempts (but not completely immune) however Im speaking about giving llms in general access to your browser broadly.
I just know through my own experiments that it is quite easy to prompt inject an llm operating a browser and get it to send secrets. Using the extension might be safer idk, Om not risking it.
Llms are a security nightmare when connected to the web.
I have a website where I experiment with this. Although Ive stopped baiting llms into doing reckless things.
Killai.now <--(dont use this, its a WIP) Killai.now/poison/about Killai.now/propaganda/about
Rather what has happened is that I have gotten very good at scanning what it is trying to do and know within a second or two whether there is anything fishy I need to look at more closely.
And by "fishy", I do not mean only security issues, but also architecture, code, etc issues. Sometimes it even adds unrelated unapproved changes to what it is supposed to be working on, and I stop it.
And I'm glad I work this way, because countless times I have stopped it from going down a path that is nonsensical or I strongly dislike.
There are techniques I have adopted to speed up working this. Sometimes I allow Claude to make larger changes at once, to batch several changes at once, etc. But these decisions are under my control.
I prefer to work this way than to wade through enormous PRs trying to wrap my head around what was done, where I am likely to just give up and approve it after a cursory review.
But this is the downside. It might be fine 99% of the time, but 1% of the time you get a critical secret published to GitHub, even after human review.
Is this even worse than what us humans did on our own before LLMs? I’m not sure. It’s not like secrets never got accidentally committed before, it just illustrates the new paradigm we’re working in.
Either you let your agents run wild, and you cross your fingers that they don’t do anything bad, or you need to accept that your new job is to be an agent babysitter, and audit every command.
Many of the problems when it comes to the manual approval feel like they stem from the expectation of using auto mode in the first place. After all, what's the point of improving the manual approval and safety matching if auto mode is the end all be all, and what's the point of training the model to output commands in a manner that can be parsed by a human if auto mode is always meant to be used? It's very rare for me to not see "command could not be statically analyzed", because the model keeps outputting bash golf.
That is not the niche case, that's the dominant use of models.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
And if everyone else jumped off a bridge, I mean, used raw interpolation for SQL queries, would you do it too?
However I do share your desire for a better manual mode. Auto-mode is both sometimes surprisingly lax, and sometimes too restrictive. Maybe manual mode should inject a reminder "keep your commands as simple one-liners", the same way plan mode injects a reminder that you are in plan mode and don't want any code changes
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.
Ultimately, the threat model here is: human has to approve a lot of commands, so gets tired and accidentally approves a command they shouldn’t have. We spent a significant amount of effort to build a richer permission system, allow configuration at multiple levels, use static analysis to detect dangerous and safe commands, monitor the model to detect and block prompt injection at the inference layer, etc. Some of these components we rewrote and red teamed dozens of times. Our conclusion was that despite all of this work, in practice the threat model is that human attention is limited and that that a different approach performs an order of magnitude better in practice.
With SOTA agents that’s a real bind, because they’re very likely to find those gaps. Whether they exploit them, close them, or leave them alone then becomes a prompting challenge yet again.
I don't think this means don't sandbox at all. You can prevent a lot of small and medium accidents by locking down or gating access to hidden files, ssh, sudo, etc.
But your sandbox can never be the whole story.
Speaking of really significant things being at risk, it's pretty infuriating that the web-chat Incognito mode can't write and test code locally, and neither the non-Incognito web-chat nor the local Claude Code client can be shielded from the knowledge of my email address and my geolocation. (Even the Incognito mode knows my geolocation.) This gives users no alternative but to put privacy-sensitive information at the disposal of Claude Code, which is far too unreliable to be entrusted with it. It's tempting to attribute this to Anthropic's corporate DNA valuing users' interests at a very low level, but conceivably it's just an oversight, and if I mention it here, it will be corrected in a month or two?
Currently, my assessment is that Claude Code, and in particular the Opus 5.5 model, is head and shoulders above the competition in software development capabilities. Nothing else is even close. But I've seen several small signs like this which suggest that Anthropic, as a company, is maliciously misaligned. So, if Grok, Qwen, GLM, or Astra starts to come anywhere close to being competitive, I'll switch as soon as I can. I imagine that most of your users feel the same way.
Maybe pick a better comparison if so?
You can make a script for the PreToolUse hook that can do that. I use a command gate script that parses input for doing that exactly, allowing/denying actions based on tool use + paths -- it started out as a hook to prevent claude from polluting my clojure projects/filesystem with python in sneaky ways. Babashka works really well here
What I mean by this is that if you restrict python execution to the entry point of your software and then Claude wants to run a command anyway so it threads it through the main.py script, you are no longer running something that is contained to your local development environment.
But when you think about it, what exactly prevents Claude from doing that anyway?
Claude could add malware into your project directly.
So the case where you say it doesn't matter which python script it can execute, actually does matter. Restricting python execution to a subset of all files buys you security.
The next step would be to get Claude to stop adding malware to your software, which it hopefully already does not do.
sed -n 1,30p src/vm/wren_vm.c && sed -n 310,350p src/vm/wren_vm.c && sed -n 560,600p src/vm/wren_vm.c && sed -n 740,775p src/vm/wren_vm.c && sed -n 40,70p src/vm/wren_common.h && cat util/wren_to_c_string.py | head -80 && ls test/random doc/site doc/site/modules doc/site/modules/random 2>/dev/null; cat projects/premake/premake5.lua | head -80; cat util/generate_projects.py
After ten or more of these, you're going to get hit by permission fatigue, and then, yes, manual review becomes too error-prone to use safely.
The irony is that Claude is regularly ignoring its existing Read/Write/Edit tools that could make everything more readable.
Other models/harnesses have their own problems, but Claude Code is one of the worst for manual approval.
You can get manual approval to work reasonably well if you give the model a reasonable set of tools (I have literally written my own MCP servers to cover gaps in existing harnesses) where you can then write rules for the vast majority of safe cases.
For example, I have a stdio MCP server that allows models to inspect crates under ~/.cargo/registry/src (paired with the existing query-crates MCP server). It provides read-only operations limited to crate data, so I can pretty safely auto-approve everything in there. With the right setup, including a sandbox, you only ever have to manually approve something once in a while and usually with delimited scope, avoiding permission fatigue.
1) edit a file with sed, 2) try to write it with its regular tool 3) get blocked because sed changed the file 4) read the file with tool 5) edit with sed again.
Would be nice if it felt like real people were developing Claude Code, instead of chasing after another half-baked idea Claude came up with.
- Yes, but only one time, you will have to manually approve next time
- Enable auto mode and stop worrying
- No
Nothing to save this command or part of it to the manual approve list. So will be requested again 100x times.
Or even reject anything auto mode rejects while still allowing the user to reject things auto mode accepts. If what's approved is the intersection of what the user is approving and what auto mode thinks is safe then it would be strictly safer than either mode alone.
This would also be a way for users to gain confidence in auto mode before going all in on it.
Ideally I would never use Claude at all outside a disposable container, even on a box with no sensitive information and with the sandbox enabled. It's like having an attacker breach your system — you don't know what it did.
"Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode" https://arxiv.org/abs/2604.04978
(Shared by hkalbert71 the other day in: https://news.ycombinator.com/item?id=50387838)
Obviously I've not given this enough design thought, but some means of providing an agent stand in secrets that cannot be used in other contexts would be a big improvement for trustability in things like cc.
If the command is explained, and then we get a chance to edit it, maybe make the rm -rf into a mv; give us UI to edit the filter being applied. I have no problem hitting "Always allow" so claude can run "git status --flags a/b/c/filename" but as a human, I'd like to be able to edit the permission blanket to be "git status *.
Which I can do manually specify in the config file, but that's annoying. I'm fully capable of opening my terminal app and editing that in vim, but I'd rather not have to. It's like this for every project too. If I start fresh on a new machine, new Claude account, how much do I need to redo?
I ended up having to build a full shell argument decomposition and parser, with it I can manage allow list of rich tree structured commands. Centralizing a curated collection of known command structures and their side effects would help a lot. I don't know if Claude does this already, but it doesn't work with things like `gcloud` from my experience, and that has resulted in it slurping secrets (even a partial read I've had to rotate keys for).
Claude uses bigquery in the command line by piping sql files from /tmp into the `bq` command. I had Claude create a hook that expands the SQL file into the permission prompt giving me a real chance to review these, but the TUI truncates long commands with no scroll option. Making that the default behaviour and adding a pager would allow better review of lots of executable scripts.
As long Claude is running as the user's account there's no guarantees. An approach like 1password's `op read` to physically separate secrets from repo read access and printing would he helpful (as in, make sure that no standard key formats can be ingested into the agent's context or logging).
Again, I don't know if any of these are implemented, they've very likely to have been tried by the Claude team, but maybe there's a long shot chance that it helps.
What if the 'settings' being described here aren't 'project settings' they're 'personal settings for the project'.
I imagine we're following dev ecosystem conventions where everybody puts their tool settings in the project folder so they know where to find it and can share it; but are agent directives like this closer to a 'tool', or closer to a 'contributor'?
If the latter, I wouldn't expect to see "Joe's personal list of naughty and nice commands" in my project files either, certainly not under 'settings'. So just don't put them there.
$Trillion AI company asking for ideas from the community whose work they hoovered up to make money, ruin an entire industry and make lifetimes of hard earned skill completely valueless in the span of 2 years.
I've always been into programming as a way to solve problems, and that CC allows us to get more done faster is a good thing.
(Up to the point that we get to RSI and extremely powerful models that we don't know how to align or control. Which I think is uncomfortably soon, and so there's a part of me that says "don't make CC better, it's on the critical path to reaching RSI before we're ready")
> Thinking through what we can do to improve this (ideas welcome)
> $Trillion AI company asking for ideas from the community
indeed always felt very weird to me. $trillion dollar company, with employees bought for as high as $100m, and a whole team/time/internal knowledge/resources/data at their disposal, asking for ideas from random individuals in some public forum? Really? How is this real? Maybe I'm missing the mark here, but it always struck me as odd.
The only thing I can figure is that since it's admittedly all vibe coded and vibe reviewed, and that nobody understands the entire system...
All ability to reason about and evolve the system holistically has been lost in favor of feeding in narrow, discreet problems to be "fixed".
There seems to be a complete lack of awareness on how flawed the security model is at a fundamental level, and that the entire sandboxing ecosystem is trying to address it at another level(like OpenShell and others).
Where do you feel the dollar threshold should be set? At $990,000 per year you still need to listen to users, but at $1,000,000 you are basically King C of Rust Mountain and they are lucky you even let them run your code?
Should RSUs and cash signing bonuses be included in the calculation?
Along with how Claude checks it in.
No?
All issues will be fixed today.
No?
It's early days, the models will improve and fix all issues.
Why would you use a tool that creates tedious and dangerous work for you?
“Oh you are just supposed to make up for Claude’s errors, and problem solved!”
What do you make of that part of the article?
Dumb if you don’t turn on auto-mode, dumb if auto-mode commits .claude.
No way to hold it right I guess?
If it's keys or secrets of any kind, you're even dumber.
If it's in a hidden directory, you are even dumber still.
If you rely on somebody stupid enough to do any of that not to commit it, you have gone beyond the valley of the ultra-dumb. Actually that's true even if you rely on smart people not to do it.
You got your dumb card fully punched when you created `.keys` to begin with.
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.
As I was reading your post I got another approval request that auto-mode did not understand. It was a single Bash call !!23!! lines tall on a retina mac display with six different variables. If anything this is the cause of approval fatigue and auto mode does nothing helpful when this is every call. I also have in my claude.md and global instructions to use tool calls rather than bash grep/cat/find, which are disregarded.
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.
I... question whether the second one is perfectly safe.
and teach Claude to not git add .
While we're at it, maybe we can also discourage the spurious use of -f for rm -- me personal pet peave
It already doesn't do this. This is from users committing the `.claude` directory themselves.
This is bullshit.
I'm one of the people who actually reads the commands, and it doesn't always get stuff right. Please don't delude yourself into thinking "auto mode" is some magic that's the right fit for everyone and every situation.
Boris, this comes off as incredibly tone deaf. I don’t want to trust the machine. Trusting the machine is how we end up here. I want to specify exact, deterministic rules that are always followed.
> "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.
Otherwise you need a broker that can verify chain of trust for the workload, but that's significantly more complexity if you're pitching a harness/app.
Ref: https://www.anthropic.com/research/investigating-unintended-...
No thanks.
Wait, I'm confused. You said yourself coding was solved, surely all you need to do is ask your AI God to come up with an idea, right?
This is such a typical blame the user response. You realize if I’m a sysadmin managing fleets of machines, this is an actual wake up in a cold sweat nightmare, even if those files never leave disk? In the past it was less a big deal, way bigger now that your machine god will just download packages and libs that have upstream malware that aggressively scans the file system for stuff like this. guess where it’s going to look first?
have more humility. jesus.
If only tools, including major ones, actually did that. Plenty of the biggest package managers in the world still write API keys in plain text to files. uv and npm are two of them.
claude unleashed on an organization is a whole other beast.
Instead of telling people they're holding it wrong, make it safe to be held however they could hold it.
Use this instead for free https://github.com/awslabs/git-secrets
The linked docs have an unmistakable slop aura, with the extreme overuse of commas that recent models seem to love. I don't blame people for not referring to them (also because, you know, the whole thing with AI is not having to read, think, or understand for yourself)
And to recommend auto made to devs is absolutely crazy.
Have a nice day
"you are holding it wrong". No, it's not an excuse. Every mode should work correctly, or should not be selectable.
Then don't put it in the fucking tree, you idiots.
No, .gitignore is obviously not enough.
More and more it seems we are being prescribed a particular way to use Claude Code: move fast, break things, do not look at the edits, etc. Basically, Claude Code is designed for vibe-coding.
I hate this, and I suspect a lot of devs do too. I use the TUI, and believe it or not, I like to review every edit or change before Claude makes it. I used to allow auto mode and don't ask again sometimes in the past, but now almost never do. The number of incredibly nonsensical things I catch Claude trying to do sometime just reinforced my commitment to this way of working.
So now this idea that permissions are old hat and auto mode is the way to go rubs me the wrong way, very much. And here are a litany of other ways Claude Code TUI is making it hard for me to work:
1. Scroll-back glitches, too numerous to enumerate. Suffice it to say I rely on it a lot, to refer back to something the agent said before, to review the general progression of the session, etc, etc. And it barely works now: missing/overwritten conversation text, messages that have inexplicably disappeared; even sometimes the agent own last response is garbled or hidden or overwritten by some previous message that keeps floating on top.
2. I use iTerm2 on macOS, and frequently use split panes. Whenever change the width of a pane, Claude Code messes up the conversation text so that is often unreadable, and nothing I do will restore it.
3. As other sibling comments have noted, the current preference of Claude to use incomprehensible scripts for editing files is off-putting and a hindrance to being in control of my work. I have resorted to using the permissions setting to ban it from using Go, Perl, Python, and sed (for in pace editing), etc, to cope with this.
4. Even basic text editing is messed up in Claude Code TUI. I used to be able to navigate around lines effectively by using up/down keys; this was removed, which has significantly impacted by work. I cannot disable copying on selection, which I don;t want, because if I disable it, the copying does not work at all, etc
At this point, due to all the impediments Claude Code places to my style of working, the only reasonable conclusion I can reach is: I am supposed to be vibe coding, letting the agents loose to vomit out massive amounts of slop. But if vibe coding of the Claude Code TUI itself is producing such garbage, why should anyone be convinced that it is a good thing?
I will never let Claude Code loose to do its thing; I will not surrender my control to it, no matter how much many times I hear I no longer need to look at code.
I don't mind. I put it out there for everyone to borrow ideas from it. There's documentation too.
While you're at it, please bring Claude Code up to par in Windows with the OS level sandboxing (Job Objects, AppContainer).
There are actually many things you can (and I think should) be doing.
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.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html