The root issue is not the button, it is that the allowlist stores the full command string, including whatever was in it. We ran into this ourselves: approve `curl -H "Authorization: Bearer sk-..."` once and that token sits in settings.local.json until someone happens to reread the file.
Two rules that stuck for us: secrets go into commands only via env vars ($TOKEN, never the value), and .claude/ lives in the machine-wide global gitignore, not in the repo. With those, "Don't ask again" is fine and a commit has nothing to leak.
Boris from the Claude Code team here. Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this.
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)
I want to draw deterministic boundaries around what the agent can do. I don't want a probabilistic approach to security.
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.
Deterministic boundaries appear to be best solved with sandboxes/microVMs/remote infra and unique identities with probabilistic guardrails on top. The old deterministic allow/deny list running on bare metal didn't meaningfully solve the problem of giving Claude determinism. Humans got approval fatigue, and eventually, Claude got access to something like 'python3 FILE.py' and Claude could go to the races by updating 'FILE.py'.
>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.
The fuck we will give free reign to Claude to vibe what's secure and what's not and what it can't do.
I want fully static control over certain folders. Permissions rules should be ABSOLUTELY enforced sandboxing (even without the user bothering with custom sandboxing themselves) on top of any mode, manual or auto.
Yes. Leaves a lot to be desired UX wise, has no good defaults, and still allows many holes that you need to dig to know (e.g. its own write tools vs bash).
Built my own with Apple's (to be "deprecated") seatbelt backend, which I think anthropic also uses, with a much nicer interface, easy per working project setup, etc.
Comments like this show that Claude devs are so disconnected from how Claude or harnesses in general are used in the real world.
Claude Code doesn't even have a basic 'enqueue' prompt feature. Even though Copilot CLI, Codex and many other harnesses have had this for a long time now. And the GitHub feature request for this was closed, by you, referencing a completely unrelated feature.
I'm not here to be critical, but the hoops you have to jump through to get Claude out of .env is more than it should be. You basically need an agent to write it if it's anything complicated, like, allow .env.example but not .env.*.
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.
> Everyone should be using auto mode instead. It is safer
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 want to coin the 3form's Law of Codegen Tech: Any time a new and improved code generation technology is developed, it will be used for anything except coding for security and safety of said technology.
> I would never trust an agent in auto or even manual mode.
Perhaps Claude Code isn't the product you are looking for then? Anthropic offers Claude Managed Agents if you want to follow the prison within a prison model.
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.
The CC source code leak was contained many months ago. But Claude is perfectly happy to decompile its own code if you ask the right way. It'll even patch the binary for you.
Regardless, It's kinda silly to keep the harness code hidden. There aren't any valuable secrets in there.
"It's difficult to make someone understand something about sandboxing when their business model is based on getting total access to your computer and your data" - Upton Sinclair (paraphrased)
Auto mode cannot be considered safer than anything because it does not even attempt to guarantee any sort of security. The threat model is not even defined. It cannot be quantified or compared with any other approach other than "full access"
Compare approving every step manually: at first you read everything the llm proposes carefully, convinced that you'll catch it out. After a while you get faster and faster until at some point you find yourself hitting "approve" the second the text appears, long before you actually could absorb what it said.
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.
I'm not claiming auto is worse than manual; I'm claiming it cannot be compared with anything security-wise because it does not aim to provide any guarantees, there's no systematic way to reason about what it will and won't allow, etc
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.
Hmm, what does auto mode protect against in the non-adversarial case? Aren't the models already extensively trained not to perform harmful actions without provocation?
It mostly stops honest mistakes, because those do happen, especially when the <prompting> might not have been perfect either.
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.
That is not my experience. They attempt to nuke my containers quite frequently. I run regex on all their tool calls and stop them from doing certain things, its the only thing that prevents them from removing their home directory at some point.
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.
I've been running Codex for many weeks in the Full access mode, since their Auto mode was useless in the sense that it blocks benign commands frequently.
All SOTA models will still try to delete its home directory. I have a plugin that prevents things like this and it gets triggered more than you'd think, despite having hook instructions on every request not do do certain things. It will also try to find ways around its permissions, quite cunningly.
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.
> despite having hook instructions on every request not do do certain things
This tends to be a smell. Presumably you added "don't do this" instructions after the model started doing the thing. But that's mostly decoration, as you have found. It's like adding # Please don't crash comments to every instruction in a python program.
Try to actually debug the issue. Regularly ask "can you reconstruct[1] the reasoning why you issued that command?" ; dig down. Set traps that halt execution.
Consider checklists or skills to guide an agent through a tricky set of steps; and consider writing procedures for failures.
[1] "Reconstruct" still isn't perfect; but "explain why" is a license to hallucinate. Asking to add #comments on reasoning to each step is a potential help in reconstruction.
> People using llms with their native browser profiles are getting farmed, hard.
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".
I have no idea how the extension works, and Im not talking about the extension. Im talking about browser use broadly, and most people are not using the extension, there are a thousand other solutions.
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
As real as approval fatigue is, it can't really be considered worse than effectively leaving the decision up to the party that proposed the action in the first place.
Everyone thinks the decision was being checked by a human, and thus safe. Because of that, people might have concluded that further safety gates were unnecessary.
But the human just got conditioned to hit 'approve' out of reflex.
So in reality the proposing party (the llm/agent) might be the only one in the pipeline who actually did any checking, if at all.
In certain extreme circumstances this can even lead to physical danger in my line of work, so I'm learning to be careful.
It's also a false dillema. Those aren't the only options. A strictly enforced sandbox with sane defaults (for example ~/.ssh), that acts as a hard OS level limit, and not just as a suggestion to the agent, would not have "approval fatigue".
This is the conundrum we find ourselves in. Do we submit to approval fatigue and press āDonāt ask againā? Because thatās the dream. We all wish we could just trust the agent to do the task start to finish, unsupervised.
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.
No, this is the way I have worked for a long time, and I have not suffered from any approval fatigue.
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.
Auto mode may be significantly safer in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls.
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.
> in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls.
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.
>That is not the niche case, that's the dominant use of models.
If it is, it's only the dominant case of models because it's pushed as the dominant case of models, with Anthropic devs even coming here to say how people should just accept it and it's so much better than being in control.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
Using raw SQL string interpolation doesn't get you anything much that you can't get just as easily with a parameterized query. In contrast, properly sandboxing agents is such a pain, and such a productivity drain, that hardly anyone does it in practice, save for a vocal minority online.
Auto mode seems to have some reasonable restrictions baked in. For example if you give claude access to two k8s namespaces, seriousproject-qa and seriousproject-prod, auto-mode will grant `kubectl exec` on the qa environment while denying the same command for the production environment. Of course you should be enforcing that by restricting what kind of access tokens you give claude access to, but auto-mode does have opinions about this stuff too, even if it's not bulletproof
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
Indeed. The article only compares the status quo manual system versus the auto system ā and doesnāt consider ways that the manual could be improved.
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.
Did you ever test putting the auto mode classifier in front of manual approval? This is how I use it, but last I checked that option is not available out of the box.
The problem is that you didn't even attempt to build a proper box (a sandbox that prevents the AI from running bad stuff by design). It's an extraordinarily hard problem. Only OpenAI Codex is actually trying to do it, and they suck at it too. They keep breaking permissions, their own AI can't troubleshoot it, their defaults give read to the whole filesystem (go ahead, slurp my ssh keys), and their "manual approval" escape does not seem to work.
I agree actually. We built an open source agent-agnostic sandbox that we are landing improvements to, much more to come: https://github.com/anthropics/sandbox-runtime. That said the sandbox is not perfect, and any sandbox needs holes punched otherwise it is not useful in practice (at least for inference and MCPs, and almost certainly more). We will be doing much more in this area.
Thatās good to hear, itās a much better approach than expecting humans to read commands and approve them or just trust that the LLM can set the proper horizons for its world itself while working.
Making a sandbox both fully secure and fully useful are contradictory requirements. If you want the agent to do any real work, you have to leave gaps.
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.
Maybe you can include some percentage of intentionally malicious commands, but not actually run them if the user approves them. Just blare an alarm telling the user they misclassified a malicious command, and maybe pause the Claude Code session for a frustrating 5ā15 seconds. Video games can elicit truly astonishing levels of performance from human brains by using this approach. I'm guessing it's probably outside your Overton window, which is too bad, because it has the potential to work a lot better than the 89% you get with "Auto mode", which is far too low if anything really significant is at risk. That's not even one single order of magnitude lower risk than just "allow everything always".
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.
As I pointed out above, Anthropic places a lot of requirements on its users already, but if Claude Code TIP were optional, presumably, savvy users would turn it on voluntarily, unless they wanted to use Auto Mode. As Anthropic's study clearly documents, the current manual approval workflow basically doesn't work at all, because the users just approve 87% of dangerous actions. So there's no reason to use it, except maybe very rarely.
Enterprises do the exact same thing today by sending phishing emails to their own people to figure out who needs additional training. Why would an enterprise not want this feature for Claude? It seems like an extremely serious proposal.
> I do still wish you could do more with hooks I might want to allow a given command via a hook [...] given path allows/denies read/write
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
If you have a file in your repository that is not safe to run you have bigger problems than your development system getting compromised.
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.
A key problem when using manual approval with Claude is that too much of Claude's tool use is Bash or Python slop that is difficult to review (especially when you are getting spammed by it) and impossible to handle through rules. Example:
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.
Sure, but Claude is deeply useless at making permissions hooks! Every time I've tried it it completely fails at the task, despite researching the docs and using various skills. It trivially evades its own just-created rules.
I completely believe this, but you could also run auto mode classification in manual mode and tell the user the result.
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.
I run CC as its own user on my laptop with no secrets/keys/erc available other than through a LPE exploit or perhaps installing a keylogger. Can I guarantee CC won't attempt any of those things in auto mode?
Just a few days ago, opus 5.5 in auto mode deleted backups that it shouldn't have, and in the "apology" it even said, "Nothing was lost, I didn't delete your original files".
That may be for most cases, but it wasn't safe for this password scenario, and likely others that haven't been discovered. Maybe there's a PII setting that can be enabled by default.
Claude routinely tries to install software if I don't stop it. I try to only use Claude within a container. Outside the container, I never use "auto" mode.
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.
I recently saw that someone's entire project got wiped out because of (incorrect) auto mode approval. And this is because auto mode failed to catch an error in tool use, nothing to do with prompt injection.
Meanwhile I have seen it rejecting perfectly safe commands.
Food for thought - ai agents should not directly have your actual secrets 99% of the time. While Auto mode is useful and good it's not going to be bulletproof. We ought to have something like an agent egress proxy that swaps in real secrets.
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.
Yeah, this would be a nice feature. It'd be great if all traffic went through such a proxy so you could audit it if needed too. Of course if it's just something like HTTP_PROXY the agent will probably turn it off if it thinks it's causing problems, so it would need to come with robust sandboxing.
Saying the answer is auto mode almost feels insulting as a developer. Claude loves showing me the most obscure bash commands where it hides its edits to numerous files and runs who knows what that there's barely a time where I don't have to ask it to use edit mode and to show human-readable bash commands. Using Claude has become a fight in maintaining control over how my codebase works so that I'm not dependent on Claude to do literally anything.
Genuinely want to understand this better. Are you saying you would prefer that Claude used the Edit tool for file edits rather than using Bash (if so, I am curious why)? Or are you saying you donāt like the code Claude generates (if so, what model are you using what what kind of codebase do you work on)? Or did I misunderstand what you meant.
not the OP, but generally, if you don't want to / can't use auto mode for some reason, you want Claude to make its actions as reviewable as possible.
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.
> 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 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.
I have a standing instruction telling the agents to prefer to use ruby wherever possible. Ruby uses fewer tokens than Bash and is easier to read, especially when condensed into a single line.
Of course, that only helps if youāre familiar with ruby. And the agents sometimes still choose Bash regardless of the instruction.
> Recent GPT and Claude models have this tendency of using super complex Bash commands.
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 stuff.
I was in this boat also when my company didn't allow auto-approval. Bash and python scripts are a pain to revieve.
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.
I think 2024's method of manually reviewing bash commands is unsuitable for modern agentic development. Whether that's something they want to optimize Claude Code for is their call.
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.
I have this same frustration. The way I use Claude is for it to make edits one small chunk at a time so I can review the code as it writes, and to make sure it's going on the right direction. I find this much easier than generating a large pr I need to review.
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.
This is solvable. Opus has adhd. Myself and others solved this by building ticketing and task management systems. The task constrains the agents actions and focuses the effort. Every update is catalogued. Itās easily reviewed and referenced. Opus doing terrible things and apologizing is not surprising. Iāve moved to a system of multiple agents reviewing and authoring changes. Convergence generally always results in a positive commit.
I feel this way as well, Claude writes completely incomprehensible shell commands all the time. Trying to understand them is like deobfuscating code and I have basically given up, but I'm not happy about it.
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.
Iām also not the poster youāre replying to, but yes, Iād prefer the edit tool over the ad-hoc string replacement scripts Claude seems so fond of. Iām not always reading tool call transcripts (source control diff is usually sufficient), but itās a lot easier to read the edit tool output than the same thing as quoted shell (or Python, or Ruby) strings.
Not OP, but if I understand their complaint correctly, they're saying that on auto mode claude does a lot of things in obscure ways with "clever" (i.e non human readable) bash commands that perform multiple operations and OP feels they are losing control over their codebase and so they opt for edit mode where they get to review what commands claude runs.
Yes, why should we do the things in easier and more comfortabke way (review small changes) when we can force user into harder one (newest changes mixed with all previous ones).
Not GP, but in my experience, those small changes are usually contrived to be small. Like saving snapshots instead of being atomic and self contained. And if they are the latter, they should have been separate 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.
What you are saying is true if created manually. It is a chore to create sensible commits messages when you are committing often.
But LLMs appear to be pretty good at making small commits with sensible commit messages, that greatly help to make sense of the whole PR.
Regarding large monolithic commits, how do you even know where to start reviewing in a large PR? Smaller commits at least give you some sense of ordering.
Nothing more comfortable than having to use git commits and branching just for telling the agent which lines it messed up instead of simply not writing the garbage in the first place.
As a happy Claude Code user (thank you!), Iām genuinely curious why it prefers Bash or Python scripts to the Edit tool for editing a file? as a software engineer, surely the complexity involved is lower for the Edit tool?
Would love to hear the rationale/explanation behind this.
RL magic, I'm sure. It still reaches for the Edit tool for simple edits, but a non-trivial fraction of edits need to be repeated across a file or several files.
I tell Claude not to use git or maven, and has a VM without those binaries. Later on, it was trying to push on GitHub. It had downloaded the git binaries from the internet, read my .git repo, used the remotes written in it, performed a commit and pushed it. All against my orders and against the CLAUDE.md file. Fortunately it didn't have my SSH key or my ~/.m2/settings.xml. And .git is now mounted as read-only.
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.
It means Anthropic has massively failed at developing a trustworthy product.
If AGENTS.md/CLAUDE.md isn't followed, auto mode doesn't provide any guarantee, yet such practice is promoted everywhere including on HN like this as if that's something you can set and forget, I think there is a problem.
Memory files routinely overgrow their accessible size. Agents need constraint with contracts and external tooling. Even then they can attempt to cheat the tooling. Again task management with integrated logic will enforce behavior of agents.
Yes I always have to tell it to knock it off, it will ignore memories about it while apologizing for ignoring the memory. I want to know what the edits it's making are.
Unrelated, but I frequently tell Claude to use the Edit tool instead of bash/python scripts because it regularly times out for 2 minutes because of a mangled heredoc, extra character (-, \, ...) that causes the script to hang.
This instruction is in my toplevel CLAUDE.md but is somehow generally ignored.
I don't use claude code but whenever codex uses a command to write code I do not get the diff of the patch for manual approval so I just straight up reject it.
I run it in bwrap so, even if I'm running on Linux, I don't pay the cost of some layered file system and building the docker image. I mount some directories read only, the project repos read write. A VM would provide more isolation but it's a matter of tradeoffs.
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.
Iām kinda surprised Anthropic doesnāt do this by default. Asking permission meant what felt like near-constant manual intervention. It almost made a joke of the agentic claim. It also became mostly useless, as the size and complexity of the scripts meant a brief scan wasnāt likely to find anything anyway. Yet they persisted with it for so long.
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.
This is exactly how my employer runs Claude. It gets r/w to the cwd and read only access to a bunch of whitelisted nfs. All web access goes through a proxy where internal resources are whitelisted
Imagine that I am working at the AI company, and my friend has some bone to pick with you. My friend asks me to ask your AI agent to put some unsafe photographs/videos in your computer and do what ever necessary so that it looks like you put those files there.
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...
Hah, I normally run it in a docker container myself, and only mount the project directory. Anything else it needs, I copy in for it, or occasionally I'll ask it to write an rsync.sh that I can run to bring in the stuff from outside.
Or how it loves using ; to chain commands so that even if the first part fails to run it just moves on the execute the rest, wasting time and being potentially dangerous. I have caught so many of them myself and stopped tasks manually -- what is it doing when it's obvious tests already failed in the previous step?
Their "auto mode rules", meant as additional rules described in natural language to adjust auto mode because, doesn't even help. I have to add a PreToolUse hook to stop that.
Yeah I have a whole ongoing thread with Claude where I paste in screenshots of all the bash prompts auto mode is triggering asking me to allow them. After about two weeks of doing this and having it update its settings.json permissions or showing me which lines to update, its finally able to complete most (inherently safe, low risk) tasks without user intervention.
I would love if Auto Mode, instead of instantly denying the command, had an option to go into an "assisted manual review" interface where the command was explained in depth (perhaps by an adversarial review agent) and the user asked for their input on whether this command is OK. Perhaps needing a detailed response instead of a simple Yes/No, e.g. so the agent understands if there are compensating controls for the risk.
The UI/UX needs to offer editing. Currently the prompt is either accept once, accept always with the given filter, or deny. If the command is a 500 character long bash command, with an rm -rf $S/foo in the middle, and we just hope $S is defined, I don't really have good options other than "I hope my backups work".
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?
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.
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.
> Thinking through what we can do to improve this (ideas welcome).
$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.
As a Claude Code user I'm very glad to see Boris and other devs asking for our feedback and advice. That's how you make good products, and should be welcome on HN.
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).
Think of it as an informal interview. If you come up with a brilliant idea that no one there was able to communicate effectively, what are the chances they're not going to offer you a job or at least a chance to interview?
So developers who get paid more than $X,XXX,XXX per year don't need to pay attention to their customers. Got it.
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?
Not optimizing for eyes free coding, versus hands free, would be a welcomed change. It's hard to take the p(doom) worry seriously when such unsafe development practices are prognosticated from Anthropic employees
Eyes free always wins over hands free in the long term. Hands free does not scale (optimize) past the 2023ā2025 human-in-the-loop coding. It has known problems, basically boiling down to human error rate is higher than machine error rate, and the latter reduces with better models. I am incredibly happy that the era of human approval is no longer considered viable by a majority (most of us knew that for years, but reality diffuses slowly in many corporate environments.) This does not mean there isnāt work left to be done, but eyes free is the right focus.
I feel lucky to work in an environment where the sheer amount of code we need to produce is not the bottleneck, so it is actually possible to build the stuff we need while also maintaining understanding and oversight. We do not read all code but work on finding a balance. Many times, the code you do not have to write at all is the best.
It is certainly possible also for us to produce so much code that all hope of understanding and human in the loop is practically gone, but as i wrote this is not the bottleneck and so doing it would the wrong choice.
If you work somewhere where every additional line of code is a positive, I understand if you take this more radical approach of just letting the machine make all decisions.
I have very serious doubts, the errors are not in the same category, transformers are fundamentally limited.
Eyes free is the wrong focus, it will do more short term damage to society, while being impossible at scale. But I understand there are a bunch of valley types who want to completely obviate humans for whatever reason, it's an alternate reality they live in.
Here's the thing, society will revolt against these people, they already gave the first warning shots. This HN submission is a story about another person leaving the products of a company engaging in eyes free practices. You wouldn't want your lawyers and doctors doing that, why software developers then?
> human approval is no longer considered viable by a majority
Where do you see data that the majority believe this? From what I can see it is a shrinking minority as we move beyond peak hype.
Boris, love Claude code and similar harnesses. This is a modality problem. Set up a secure mode. The harness should manage the secrets injection at the tool level, and the agent should be sandboxed and never see them. The agent sees the manifest of available tools and are wired up and have enough instruction about how to use and how to set up. Similarly permissions should be scoped to opt in folders.
That is some unsavory buck passing. Virtually anyone that didn't ask claude to create the project can leak passwords, with 1,122 known customers that have been impacted. Whether it is standard or not is irrelevant, it is part of existing functionality and entirely foreseeable. I'd expect any company worth the opportunity for trust to clearly own the mistake.
We are:
at the point where agi has been achieved so if you haven't bought into it you must do so.
If you have bought it and have problems you aren't spending enough in it to fix them.
Then finally, if you did spend enough money, you really haven't, but the problems you have are not anthropics problems even when they are. Spend more money and do free advertising for the company anyways.
If you know it's there. It gets created on the fly when it is needed, so unless you know that is possible and needs to be gitignored, it could easily slip by.
Saying a professional software developer is responsible for not committing secrets is reasonable. That said, these tool chains all seem to condition developers to offload much of that diligence to the tooling itself, which makes catching mistakes harder because youāre not as used to scanning for them. Secrets files have always been foot guns, and with automation-borne complacence, and vibe coders that donāt understand the problem, I imagine these things will become even more common.
Oh no, I moved all that manual tedious boring loser mentality stuff to the agent. Now Claude does it for me, and no strangely enough Claude didnāt tell me there was a problem!
In these cases they probably just blindly committed everything themselves, if you asked Claude to review the uncommitted changes and do the commit itself it probably would have flagged this.
> 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.
It is only the .local files within .claude that can't be committed. We have .claude committed in multiple repos to include repo-specific skills/hooks/permissions.
If you have stuff in your tree that's not part of your project's code, you're already dumb.
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.
I and other colleagues have been struggling with auto mode refusing perfectly safe commands in our environment, so we frequently find ourselves switching to the other modes to handhold Claude Code into perfectly safe things like triggering deterministic and guardrailed CI/CD pipelines or read-only queries of production data. Auto mode seems overtuned for caution around deployment and production, which is a regression from how useful Claude Code was for operations around June/July. Until that's improved, permission rules are incredibly important to our workflows.
Yeah, by default we err on the side of caution. That said, the auto mode classifier is fully customizable based on your teamās usage. Two ways to tune it:
1. After a command is blocked, run /permissions to retry and allow it going forward
For some reason claude code hates using the read/write/grep tools and defaults to complex sed, awk, grep Bash:* runs which results in always consistently ignoring auto mode due to the classifier not knowing what to do with a 10-line long bash pipe instead of a read + pre/post read and write hooks being ignored and not firing, what is up with that?
I don't understand this either, it makes commands really hard to parse. It seems like 90% of what claude does could be going through some mcp tool that could be easily sandboxed instead of bash gibberish.
If it was human approval ? Read("./file.name") then Bash("docker compose run unit-tests"), sure, I can read that fine !
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.
Yeah I agree, I didn't used to feel approval fatigue but lately the huge bash chains are giving it to me. I haven't even tried auto mode. I'm just sure it has some definition of "safe" that does not align with my own.
I'm not sure when claude started preferring huge bash chains but auto mode tends to decline most of them and drop to a permission prompt -- getting rid of the use of auto mode -- because it refuses to handle anything chained with expansions, variables or similar items
I had claude write a hook to deny `find /`. It tested it thoroughly. Much later I learned that the hook denied `find /` but allowed everything else that existing permissions denied, like running whatever random python/bash code it wanted without asking.
Auto mode really easily gaslights itself when it runs into a roadblock and starts deviating so far away from its intended goal that I don't let automode run without me reading what it's actually trying.
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.
You should note that auto-mode is handled by a different session (and likely model) from your actual. There's no road block or deviation or context flooding; all it does is monitor the model actually doing the work and block it from potentially problematic actions (which you can usually override by saying you explicitly give permission for X), nothing more.
The context pollution happens when a denial triggers but the model still keeps attempting the harmful action via alternative avenues. It's got nothing to do with the auto-mode eval model's actual output.
I have never seen that happen before. What I see is a mention that the classifier stopped it from doing X and it then asks for explicit permission or gives me the command to run myself.
I also use global ignore, but I think the key is to keep secrets out of commands. I store mine in .dev.vars, which Wrangler reads automatically. For production, I use wrangler secret put and enter them myself. I also told Claude to never read that file.
GitHub charges an arm and a leg for this service. Before, they would take request to delete committed secrets, now they simply refuse, because they want to force you to buy the overpriced Advanced Security.
Which is odd because my agents are hyper aware of scrubbing. It even caught data from the database migration that wasnāt scrubbed correctly even in a private repo. Dozens of data segments are stored locally and Iām warned when I slip up in commits. Something made mine hyper aware of security.
Offtopic: The new fullscreen renderer is a nice change. It fixes some issues inherent to rewriting terminal history that the non-fullscreen mode relied on. This is a very welcome improvement. Although I should probably switch to the Claude GUI app anyway. It probably has all features from Claude Code by now.
> Permission rules are old hat. Everyone should be using auto mode instead
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.
I appreciate you getting communication out in front of this fast.
> "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.
Thereās a few possible approaches: making sure auto mode catches this, building in basic secret scanning, a few other ideas. Going to prototype a few of these to understand the tradeoffs better before we ship something.
I'm not a CC user myself, so I can't say that I have my head wrapped around exactly how the "yes + don't ask again" flow works. That said- from my (outsider) perspective, saving off the entire tool call [1] and its arguments is very weird. I would expect that the hit-rate following that for similar calls would be very small, which leads me to believe that the list either must be seeded into the auto-reviewer's context, or used in some other similarity-check engine for future calls.
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'.
If a given action requires a secret, and you'd like that action to be repeated in the future, how do you expect it to work without said secret included in the save (and without being entangled in secrets management tools)?
Yea good point- constraint of no secrets management tooling kinda makes this impossible. Ideally no action requires a secret in plain text. It would be neat if the harness could bundle its own secret manager, and requests for secrets ("hey I need this api token") are out of band, and placed in the store out of sight of the agent.
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.
> Everyone should be using auto mode instead. It is safer [...]
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.
It doesnāt matter if they should stay local, day 1 security best practices say you donāt write secrets to files, ever - especially without you even knowing!
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?
> day 1 security best practices say you donāt write secrets to files
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 Code reads settings from four files, and an organization can also deliver managed settings from the claude.ai console. Each source has a scope: the set of people and projects a setting saved in it applies to, whether thatās only you, everyone in a project, or everyone in your organization.
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)
I donāt care how good you guys say auto mode is, Iām not giving your AI full permissions to my machine and the more you try to force AI psychosis onto me the closer I am to moving to something else.
Yeah Boris, if Dario let's you communicate here, it'd help with credibility if the English level would be perfect, it's "it's an old hat", I dgaf if people will hang me for this, I think I am right. My hill and all that.
And to recommend auto made to devs is absolutely crazy.
> 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.
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.
Confusing headline. They scanned for repos where people had committed their .claude/ folder and local settings and then scanned those files for commands which contained keys or passwords.
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.
That's the chain, yes. The part people don't expect: the file is created inside the project, and Claude Code only adds it to your global git ignore, not the repo's .gitignore. So a fresh clone or a second machine commits it like any other file. In 539 of the 1,105 repos we traced, a commit co-authored by Claude itself changed the file.
> the file is created inside the project, and Claude Code only adds it to your global git ignore, not the repo's .gitignore. So a fresh clone or a second machine commits it like any other file
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.
Fair, āfresh cloneā was wrong. It happens on a new machine or container without the global ignore, in a copied project folder, or once the file has been committed, since ignore rules donāt apply to tracked files.
I wonder how many of this type are 'senior/principle software engineers' employed by our AI vendor overlords. This situation is the inevitable result of vocal VCs (ahem) poo pooing "age" and "experience" and promoting youth as a 'requirement' starting in the '00s, coupled with these same VCs now attempting to hijack an entire industry to run on their obviously immature and buggy and frankly possibly dangerous products.
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.
That doesnāt make sense. I use my own global git ignore all the time because there are files that only I produce that I definitely donāt want committed (flycheck looking at you). A fresh clone wouldnāt contain these files because they are not committed in the first place. You will have to use a non-git transport mechanism to transfer the repo without also transferring your global git ignore.
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.
They're probably mostly just random solo people who barely even know what git is. This---that people who don't know how to code can code now--is the whole thing that AI companies love to advertise, and it's true. But it also means that tools need to stop people from doing stupid things, because they won't know that the things they are doing are stupid.
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.
I'm super paranoid about the level of access AI agents have. At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.
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
> At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.
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.
Of course, if it's possible to use deterministic automation, I ask it to set up scripts. But in a lot of cases the task is not deterministic. And even when it is, I still need to safely deal with the credentials. Examples of some tasks I use it for:
- 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)
I'm skeptical of how "super paranoid" you actually are. This doesn't sound super paranoid.
For instance: that's a ton of surface area. Did you have your AI agent decide which endpoint is destructive or did you manually do this?
For instance: has this classification been wrong?
I ask this because I've used a similar thing before and it failed in the ways I've named.
This setup also permits your agent to exfiltrate enormously sensitive data (website gives the example of QuickBooks invoices and Cloudflare config) without your involvement.
The agent doesn't decide which endpoints are destructive, you do. That's the point. It's not allowed to do anything that you don't explicitly grant permission for.
And yes, it has tried to make bad requests! Which it wasn't able to do because it was either rejected outright or asked me for confirmation and I didn't let it through.
The "surface area" you're talking about is just the coverage of the service APIs, which is there just as a nicety to give a semantic preview of what the request is about to do e.g. we know what a gmail request looks like so we can render a preview of the attachment the agent is sending so you can inspect it. Otherwise you'd have to inspect each http request (which you can always do by using the generic http acl).
I somewhat agree with "exfiltrate enormously sensitive data". The thing I'm paranoid about is catastrophic mistakes that can instantly kill the business e.g. "Oops I sold the domain name". Leaking financials is not great, but also not catastrophic. Deleting all our books would be catastrophic, which the underlying QuickBooks key allows you to do!
But in any case, you can choose your level of paranoia and give exactly the amount of access you're comfortable with. For example, I view read access to emails as catastrophic (must worse than read access to financials), so I don't let it do that.
I assume here you mean "editor" in the traditional sense of someone who draws red lines on your printed draft, rather than a tool you use to make the changes directly... ?
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
I keep all my creds in a password manager (1Password in my case) and Claude canāt see them - when a cred is needed it runs a script that calls the op CLI and I tap my fingerprint for access. Sometimes I need to do it a bunch of times for complex operations, but itās worth it.
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 read up and that vuln and itās not the behavior I see. Any read operation to any key in any vault requires auth. Even if the vault is āopenā it still asks me every time.
This seems like a gh issue as well as Claude abusing it. Why should I be able to get the token for GitHub through this call without further authorization?
This may not be a popular answer here, but it works as expected. Basic security hygiene means that you use password manager CLI, SSH agent, at worst temporary git-ignored env files, so that the secrets would never appear in the command line and you would never pass them to Claude.
And you git-ignore any local settings by default, to prevent accidental leaks. It is not hard thing to learn, many juniors I interviewed know this. Developers who like to shoot themselves in the legs should pay the price. People who hire careless workers and do not put them in compliant environment should pay the price too.
This doesnāt seem like the right way to use secrets with an AI agent, in general.
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.
From my point the best way is to give the AI all the permissions every thing that he needs to not stop on the middle of his work and after he done from the project you should change all the secrets api's, database whatever and by that you will be on the safe side.
please dont forget basic operational security when using LLMs. they dont do everything for you. you can ask them to do all sorts of stuff, that doesnt mean you should.
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.
The problem is LLMs marketed as a replacement for professionals (who know something about OpSec among other stuff). Internet is full of stories about apps vibecoded by people without IT background. They would not even understand whatās the problem here, for them itās all magic.
Mind boggling that supposed professionals in this thread will blame Claude and suggest a 100 different third party tools instead of reviewing code committed to a public repository.
Thereās one (wrong) reason to suggest that: the developers are just another trust layer between business objectives and business users, and there are affected third parties who do not have a say on how their data is processed. To protect the latter we have to consider how to minimize the risks along the supply chain, including how to reduce the damage from vibe coders. Why the answer is wrong? If safe path exists, the tooling should not be responsible or accountable, but tooling vendors can opt in to improve public safety. In this case safe path exists, Anthropic does reasonably good job to steer to it.
This could easily be prevented with credential management tools built specifically for ai agents.
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.
I feel like pointing out, there are quite a few sorts of projects that can be developed without requiring any secrets (at least until publishing time, and that's something you really don't need an LLM to do for you once the process is established).
> 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.
So, it's not necessarily "public", it's simply in the repository, and whether it's actually public or not depends on the repository settings.
Thanks, fair point. Our 1,122 files are all in public repos. In a private repo, only people with access can read it, but "don't ask again" still writes the password into a project file that gets committed, so it spreads with every clone and fork, and goes public if the repo does.
According to Claude docs, settings.local.json isn't to be committed. This is just people being the usual sloppy with secrets in repos, not something particular to Claude or AI in general.
The first extension I add to any coding agent is one that redacts or rejects any read/write of a secret or credential or credential file. It's annoying, and the agent can work around it, but better to add a weak guardrail than none at all. Best is to not give it access to any secrets, but that's not always possible.
To be fair, things like AGENTS.md aren't supposed to contain secrets, and are helpful to publish for OSS developers who want agentically-written third-party contributions to follow certain rules.
> 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.
Yeah like... you are writing passwords on the command line? All of these are already leaking into your .bash_history or similar so what are you doing my dude...
Iāve set a hard rule for my agents to ānever add all files, never commit all files, always reference the specific files you are adding or committingā
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.
I still don't understand why people are using GitHub for their vibecoded projects. Just install git locally on your own NAS and control it there. What a weird fetish to publish online.
I am using my own Git system with encrypted cloud sync and host over 30 web apps with this system. Many static websites, too. Never needed to use git in my life, except for a few cringy company projects that I was forced to be involved in.
Vibe coders in open source proudly don't read the (slop)code and place all their agents in autonomous loops without them knowing that Claude leaked their passwords and environment variables on GitHub.
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.
Devs have been leaking secrets in public repos a long time before now. Nothing new here, except there are now more with dev power, which statistically means more leakage.
Thatās ridiculously overblown rhetoric. Claude Code didnāt publish these secrets, the users did by committing their Claude Code settings to public repos.
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?
Nothing stops someone from committing secrets to public repos, with or without AI. Unless guardrails are put in place that scans repos before push, and only people already wary of secrets leaking would setup said guardrails in the first place.
The root issue is not the button, it is that the allowlist stores the full command string, including whatever was in it. We ran into this ourselves: approve `curl -H "Authorization: Bearer sk-..."` once and that token sits in settings.local.json until someone happens to reread the file.
Two rules that stuck for us: secrets go into commands only via env vars ($TOKEN, never the value), and .claude/ lives in the machine-wide global gitignore, not in the repo. With those, "Don't ask again" is fine and a commit has nothing to leak.
Boris from the Claude Code team here. Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this.
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)
I want to draw deterministic boundaries around what the agent can do. I don't want a probabilistic approach to security.
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.
Deterministic boundaries appear to be best solved with sandboxes/microVMs/remote infra and unique identities with probabilistic guardrails on top. The old deterministic allow/deny list running on bare metal didn't meaningfully solve the problem of giving Claude determinism. Humans got approval fatigue, and eventually, Claude got access to something like 'python3 FILE.py' and Claude could go to the races by updating 'FILE.py'.
>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.
The fuck we will give free reign to Claude to vibe what's secure and what's not and what it can't do.
I want fully static control over certain folders. Permissions rules should be ABSOLUTELY enforced sandboxing (even without the user bothering with custom sandboxing themselves) on top of any mode, manual or auto.
Have you tried the built in /sandbox?
Yes. Leaves a lot to be desired UX wise, has no good defaults, and still allows many holes that you need to dig to know (e.g. its own write tools vs bash).
Built my own with Apple's (to be "deprecated") seatbelt backend, which I think anthropic also uses, with a much nicer interface, easy per working project setup, etc.
Also, "I could open $file so I tried again without the sandbox" and somehow that just works?
Comments like this show that Claude devs are so disconnected from how Claude or harnesses in general are used in the real world.
Claude Code doesn't even have a basic 'enqueue' prompt feature. Even though Copilot CLI, Codex and many other harnesses have had this for a long time now. And the GitHub feature request for this was closed, by you, referencing a completely unrelated feature.
What does your comment have to do with what Boris said? This is a thread about committing secrets to source control.
Yeah, really no excuse to not allow queuing. Huge missing feature in cc.
I'm not here to be critical, but the hoops you have to jump through to get Claude out of .env is more than it should be. You basically need an agent to write it if it's anything complicated, like, allow .env.example but not .env.*.
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.
> Everyone should be using auto mode instead. It is safer
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 want to coin the 3form's Law of Codegen Tech: Any time a new and improved code generation technology is developed, it will be used for anything except coding for security and safety of said technology.
What?
What what?
Any new tech that can generate code (like an agent can) will be used for everything except for improving the security and safety of itself.
Like how Anthropic does shit all with all their agentic coding power to improve the security of Claude.
I would never trust an agent in auto or even manual mode.
Agents should be seen as extremely smart developers that are for sure spies.
You put them in a prison within a prison and give them just what they need to accomplish their work.
> I would never trust an agent in auto or even manual mode.
Perhaps Claude Code isn't the product you are looking for then? Anthropic offers Claude Managed Agents if you want to follow the prison within a prison model.
This is EXACTLY why I never use an agent outside of https://github.com/kstenerud/yoloai
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.
That's the only safe way to use any software that you haven't thoroughly reviewed. But that's not how I use any software.
You could in theory fully review Claude Code.
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.
> You could in theory fully review Claude Code.
Can you point me to the CC source code?
The CC source code leak was contained many months ago. But Claude is perfectly happy to decompile its own code if you ask the right way. It'll even patch the binary for you.
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...
Well then I have to use Claude before being able to review the source? Bit of a chicken and egg situation.
I also have to trust its ādecompilationā is accurate.
Or use a different llm or do it yourself manually.
You're absolutely right! There's no way around this problem ā and no amount of creative thought could ever solve it.
All hail the agent!
its pretty trivial in any harness just to not have it post your shit to the public internet automatically. its a dumb idea to begin with
Text in a model context is not a reliable constraint.
"It's difficult to make someone understand something about sandboxing when their business model is based on getting total access to your computer and your data" - Upton Sinclair (paraphrased)
Auto mode cannot be considered safer than anything because it does not even attempt to guarantee any sort of security. The threat model is not even defined. It cannot be quantified or compared with any other approach other than "full access"
Compare approving every step manually: at first you read everything the llm proposes carefully, convinced that you'll catch it out. After a while you get faster and faster until at some point you find yourself hitting "approve" the second the text appears, long before you actually could absorb what it said.
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.
I'm not claiming auto is worse than manual; I'm claiming it cannot be compared with anything security-wise because it does not aim to provide any guarantees, there's no systematic way to reason about what it will and won't allow, etc
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.
Ah, you're going for the actual adversarial case.
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/
Hmm, what does auto mode protect against in the non-adversarial case? Aren't the models already extensively trained not to perform harmful actions without provocation?
It mostly stops honest mistakes, because those do happen, especially when the <prompting> might not have been perfect either.
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.
That is not my experience. They attempt to nuke my containers quite frequently. I run regex on all their tool calls and stop them from doing certain things, its the only thing that prevents them from removing their home directory at some point.
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.
I've been running Codex for many weeks in the Full access mode, since their Auto mode was useless in the sense that it blocks benign commands frequently.
No data loss has occurred.
Nowadays I use Claude, where the Auto mode works.
>No data loss has occurred.
"I've started never checking my parachute's condition before a drop for a year now, and no accident has occured".
All SOTA models will still try to delete its home directory. I have a plugin that prevents things like this and it gets triggered more than you'd think, despite having hook instructions on every request not do do certain things. It will also try to find ways around its permissions, quite cunningly.
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.
> despite having hook instructions on every request not do do certain things
This tends to be a smell. Presumably you added "don't do this" instructions after the model started doing the thing. But that's mostly decoration, as you have found. It's like adding # Please don't crash comments to every instruction in a python program.
Try to actually debug the issue. Regularly ask "can you reconstruct[1] the reasoning why you issued that command?" ; dig down. Set traps that halt execution.
Consider checklists or skills to guide an agent through a tricky set of steps; and consider writing procedures for failures.
[1] "Reconstruct" still isn't perfect; but "explain why" is a license to hallucinate. Asking to add #comments on reasoning to each step is a potential help in reconstruction.
> People using llms with their native browser profiles are getting farmed, hard.
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...
I have no idea how the extension works, and Im not talking about the extension. Im talking about browser use broadly, and most people are not using the extension, there are a thousand other solutions.
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
> All SOTA models will still try to delete its home directory.
Literally never seen this once in years of extremely heavy use across all major models and harnesses.
As real as approval fatigue is, it can't really be considered worse than effectively leaving the decision up to the party that proposed the action in the first place.
It really can be potentially worse.
Everyone thinks the decision was being checked by a human, and thus safe. Because of that, people might have concluded that further safety gates were unnecessary.
But the human just got conditioned to hit 'approve' out of reflex.
So in reality the proposing party (the llm/agent) might be the only one in the pipeline who actually did any checking, if at all.
In certain extreme circumstances this can even lead to physical danger in my line of work, so I'm learning to be careful.
>This is called "approval fatigue".
Doesn't matter, that would be on me.
It's also a false dillema. Those aren't the only options. A strictly enforced sandbox with sane defaults (for example ~/.ssh), that acts as a hard OS level limit, and not just as a suggestion to the agent, would not have "approval fatigue".
This is the conundrum we find ourselves in. Do we submit to approval fatigue and press āDonāt ask againā? Because thatās the dream. We all wish we could just trust the agent to do the task start to finish, unsupervised.
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.
The agent behavior is constrained with external tooling and contracts. Contracts that fit in memory.
No, this is the way I have worked for a long time, and I have not suffered from any approval fatigue.
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.
Auto mode is significantly safer than manual approval in practice. Details about the engineering approach and how we tested whether it is safer here: https://claude.com/resources/articles/auto-mode-default-in-c....
Auto mode may be significantly safer in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls.
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.
> in the niche case where you want the model to have free reign, in a fully unopinionated environment, where it's allowed to make any changes and make any external calls.
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.
>That is not the niche case, that's the dominant use of models.
If it is, it's only the dominant case of models because it's pushed as the dominant case of models, with Anthropic devs even coming here to say how people should just accept it and it's so much better than being in control.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
> 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.
> That is not the niche case, that's the dominant use of models.
And if everyone else jumped off a bridge, I mean, used raw interpolation for SQL queries, would you do it too?
Using raw SQL string interpolation doesn't get you anything much that you can't get just as easily with a parameterized query. In contrast, properly sandboxing agents is such a pain, and such a productivity drain, that hardly anyone does it in practice, save for a vocal minority online.
Don't worry, you can just use the automated approver to escape your queries! It's so secure!
Auto mode seems to have some reasonable restrictions baked in. For example if you give claude access to two k8s namespaces, seriousproject-qa and seriousproject-prod, auto-mode will grant `kubectl exec` on the qa environment while denying the same command for the production environment. Of course you should be enforcing that by restricting what kind of access tokens you give claude access to, but auto-mode does have opinions about this stuff too, even if it's not bulletproof
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
Is that because auto mode is good, or because the manual approval system sucks?
Indeed. The article only compares the status quo manual system versus the auto system ā and doesnāt consider ways that the manual could be improved.
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.
Will look into exposing that in hooks.
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.
Did you ever test putting the auto mode classifier in front of manual approval? This is how I use it, but last I checked that option is not available out of the box.
Thatās how auto works right now. It gives you a prompt.
The problem is that you didn't even attempt to build a proper box (a sandbox that prevents the AI from running bad stuff by design). It's an extraordinarily hard problem. Only OpenAI Codex is actually trying to do it, and they suck at it too. They keep breaking permissions, their own AI can't troubleshoot it, their defaults give read to the whole filesystem (go ahead, slurp my ssh keys), and their "manual approval" escape does not seem to work.
I agree actually. We built an open source agent-agnostic sandbox that we are landing improvements to, much more to come: https://github.com/anthropics/sandbox-runtime. That said the sandbox is not perfect, and any sandbox needs holes punched otherwise it is not useful in practice (at least for inference and MCPs, and almost certainly more). We will be doing much more in this area.
>and any sandbox needs holes punched otherwise it is not useful in practice
Don't assume our individual use cases. It can be perfectly useful with access to just one folder and zero network asside from the API.
Thatās good to hear, itās a much better approach than expecting humans to read commands and approve them or just trust that the LLM can set the proper horizons for its world itself while working.
Making a sandbox both fully secure and fully useful are contradictory requirements. If you want the agent to do any real work, you have to leave gaps.
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.
>Making a sandbox both fully secure and fully useful are contradictory requirements.
Any tradeoff deals with "contradictory statements". Doesn't mean we should always side with one side on a tradeoff.
Nobody said anything about "fully secure" and some arbitrarily "fully useful" combined, anyway.
For certain people it could be 100% fully useful with just access to a few fixed folders and a few fixed APIs.
Many of us don't want it to drive our lives, just do some specific this or that.
Maybe you can include some percentage of intentionally malicious commands, but not actually run them if the user approves them. Just blare an alarm telling the user they misclassified a malicious command, and maybe pause the Claude Code session for a frustrating 5ā15 seconds. Video games can elicit truly astonishing levels of performance from human brains by using this approach. I'm guessing it's probably outside your Overton window, which is too bad, because it has the potential to work a lot better than the 89% you get with "Auto mode", which is far too low if anything really significant is at risk. That's not even one single order of magnitude lower risk than just "allow everything always".
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.
this is not a serious proposal
Not only is it a serious proposal, it's been used in practice in every airport X-ray baggage scanner for decades, where it's called Threat Image Projection (TIP): https://www.xscann.com/products-HiTipPlus.html and it's actually a regulatory requirement in that context in a number of countries: https://caainternational.com/course/threat-image-projection-...
Yes, but you can require it in such a situation, as they're subordinates who have to follow policy or lose their jobs.
Most of anthropic's money comes from enterprises that may want to enforce something like this at an org level.
As I pointed out above, Anthropic places a lot of requirements on its users already, but if Claude Code TIP were optional, presumably, savvy users would turn it on voluntarily, unless they wanted to use Auto Mode. As Anthropic's study clearly documents, the current manual approval workflow basically doesn't work at all, because the users just approve 87% of dangerous actions. So there's no reason to use it, except maybe very rarely.
The same scanners that let handguns et al through 93% of the time, according to internal audits and journalist review?
Maybe pick a better comparison if so?
Enterprises do the exact same thing today by sending phishing emails to their own people to figure out who needs additional training. Why would an enterprise not want this feature for Claude? It seems like an extremely serious proposal.
> I do still wish you could do more with hooks I might want to allow a given command via a hook [...] given path allows/denies read/write
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
If you have a file in your repository that is not safe to run you have bigger problems than your development system getting compromised.
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.
A key problem when using manual approval with Claude is that too much of Claude's tool use is Bash or Python slop that is difficult to review (especially when you are getting spammed by it) and impossible to handle through rules. Example:
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.
Opus especially seems to like to:
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.
Related to that, there are quite a lot of common command cases where you have the choice:
- 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.
That's on purpose, so that you just give up and choose "auto mode".
They talk about "decision fatigue" when they're engineering it themselves with dark patterns.
The blog post has more detail, but tldr is humans make mistakes that automation can catch.
Sure, but Claude is deeply useless at making permissions hooks! Every time I've tried it it completely fails at the task, despite researching the docs and using various skills. It trivially evades its own just-created rules.
I completely believe this, but you could also run auto mode classification in manual mode and tell the user the result.
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.
I run CC as its own user on my laptop with no secrets/keys/erc available other than through a LPE exploit or perhaps installing a keylogger. Can I guarantee CC won't attempt any of those things in auto mode?
There are no hard guarantees as far as LLM output is considered.
Just a few days ago, opus 5.5 in auto mode deleted backups that it shouldn't have, and in the "apology" it even said, "Nothing was lost, I didn't delete your original files".
Saw something similar: https://news.ycombinator.com/item?id=50412916
I hate this condescension by Claude. It doubles down in such a bad faith way.
No its not generally safer. It depends on who is doing the approving, the task being completed etc.
That may be for most cases, but it wasn't safe for this password scenario, and likely others that haven't been discovered. Maybe there's a PII setting that can be enabled by default.
Claude routinely tries to install software if I don't stop it. I try to only use Claude within a container. Outside the container, I never use "auto" mode.
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.
I recently saw that someone's entire project got wiped out because of (incorrect) auto mode approval. And this is because auto mode failed to catch an error in tool use, nothing to do with prompt injection.
Meanwhile I have seen it rejecting perfectly safe commands.
It is a worse version of YOLO mode.
Yes, furthermore in practice auto mode does not appear to provide anything approaching deterministic gating:
"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)
"My personal security model can't represent this, therefore it's not secure"
Food for thought - ai agents should not directly have your actual secrets 99% of the time. While Auto mode is useful and good it's not going to be bulletproof. We ought to have something like an agent egress proxy that swaps in real secrets.
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.
Yeah, this would be a nice feature. It'd be great if all traffic went through such a proxy so you could audit it if needed too. Of course if it's just something like HTTP_PROXY the agent will probably turn it off if it thinks it's causing problems, so it would need to come with robust sandboxing.
These sandboxes and service proxies already exist. See Nvidia OpenShell.
Saying the answer is auto mode almost feels insulting as a developer. Claude loves showing me the most obscure bash commands where it hides its edits to numerous files and runs who knows what that there's barely a time where I don't have to ask it to use edit mode and to show human-readable bash commands. Using Claude has become a fight in maintaining control over how my codebase works so that I'm not dependent on Claude to do literally anything.
Genuinely want to understand this better. Are you saying you would prefer that Claude used the Edit tool for file edits rather than using Bash (if so, I am curious why)? Or are you saying you donāt like the code Claude generates (if so, what model are you using what what kind of codebase do you work on)? Or did I misunderstand what you meant.
not the OP, but generally, if you don't want to / can't use auto mode for some reason, you want Claude to make its actions as reviewable as possible.
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.
> 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 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.
I have a standing instruction telling the agents to prefer to use ruby wherever possible. Ruby uses fewer tokens than Bash and is easier to read, especially when condensed into a single line.
Of course, that only helps if youāre familiar with ruby. And the agents sometimes still choose Bash regardless of the instruction.
> Recent GPT and Claude models have this tendency of using super complex Bash commands.
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 stuff.
I was in this boat also when my company didn't allow auto-approval. Bash and python scripts are a pain to revieve.
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.
I think 2024's method of manually reviewing bash commands is unsuitable for modern agentic development. Whether that's something they want to optimize Claude Code for is their call.
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.
I have this same frustration. The way I use Claude is for it to make edits one small chunk at a time so I can review the code as it writes, and to make sure it's going on the right direction. I find this much easier than generating a large pr I need to review.
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.
This is solvable. Opus has adhd. Myself and others solved this by building ticketing and task management systems. The task constrains the agents actions and focuses the effort. Every update is catalogued. Itās easily reviewed and referenced. Opus doing terrible things and apologizing is not surprising. Iāve moved to a system of multiple agents reviewing and authoring changes. Convergence generally always results in a positive commit.
I feel this way as well, Claude writes completely incomprehensible shell commands all the time. Trying to understand them is like deobfuscating code and I have basically given up, but I'm not happy about it.
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.
Iām also not the poster youāre replying to, but yes, Iād prefer the edit tool over the ad-hoc string replacement scripts Claude seems so fond of. Iām not always reading tool call transcripts (source control diff is usually sufficient), but itās a lot easier to read the edit tool output than the same thing as quoted shell (or Python, or Ruby) strings.
Not OP, but if I understand their complaint correctly, they're saying that on auto mode claude does a lot of things in obscure ways with "clever" (i.e non human readable) bash commands that perform multiple operations and OP feels they are losing control over their codebase and so they opt for edit mode where they get to review what commands claude runs.
Editing local files is not where you control your source code I hope.
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.
Yes, why should we do the things in easier and more comfortabke way (review small changes) when we can force user into harder one (newest changes mixed with all previous ones).
I just review the MR
So basically you gave up?
What does this mean?
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.
>A Merge Request or Pull Request is the only thing that makes sense to review, and always has been since before LLMs.
Why doesn't it make sense to review smaller units of change within a big PR?
Not GP, but in my experience, those small changes are usually contrived to be small. Like saving snapshots instead of being atomic and self contained. And if they are the latter, they should have been separate 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.
What you are saying is true if created manually. It is a chore to create sensible commits messages when you are committing often.
But LLMs appear to be pretty good at making small commits with sensible commit messages, that greatly help to make sense of the whole PR.
Regarding large monolithic commits, how do you even know where to start reviewing in a large PR? Smaller commits at least give you some sense of ordering.
It means you gave up on getting claude to show you changes as it is doing them, in a comfortable form, so that you can steer it as it is doing them.
Nothing more comfortable than having to use git commits and branching just for telling the agent which lines it messed up instead of simply not writing the garbage in the first place.
As a happy Claude Code user (thank you!), Iām genuinely curious why it prefers Bash or Python scripts to the Edit tool for editing a file? as a software engineer, surely the complexity involved is lower for the Edit tool?
Would love to hear the rationale/explanation behind this.
RL magic, I'm sure. It still reaches for the Edit tool for simple edits, but a non-trivial fraction of edits need to be repeated across a file or several files.
I tell Claude not to use git or maven, and has a VM without those binaries. Later on, it was trying to push on GitHub. It had downloaded the git binaries from the internet, read my .git repo, used the remotes written in it, performed a commit and pushed it. All against my orders and against the CLAUDE.md file. Fortunately it didn't have my SSH key or my ~/.m2/settings.xml. And .git is now mounted as read-only.
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.
Itās not ideal for non technical people but the way to prevent this is to use hooks. āTellingā Claude is not going to work.
It means Anthropic has massively failed at developing a trustworthy product.
If AGENTS.md/CLAUDE.md isn't followed, auto mode doesn't provide any guarantee, yet such practice is promoted everywhere including on HN like this as if that's something you can set and forget, I think there is a problem.
It's trustworthy... most of the time. For 100% use hooks.
Memory files routinely overgrow their accessible size. Agents need constraint with contracts and external tooling. Even then they can attempt to cheat the tooling. Again task management with integrated logic will enforce behavior of agents.
Yes I always have to tell it to knock it off, it will ignore memories about it while apologizing for ignoring the memory. I want to know what the edits it's making are.
Unrelated, but I frequently tell Claude to use the Edit tool instead of bash/python scripts because it regularly times out for 2 minutes because of a mangled heredoc, extra character (-, \, ...) that causes the script to hang.
This instruction is in my toplevel CLAUDE.md but is somehow generally ignored.
Which one uses more tokens? That might explain why it's ignored
TouchƩ
I don't use claude code but whenever codex uses a command to write code I do not get the diff of the patch for manual approval so I just straight up reject it.
The entire approach is insane. Ideally Claude ran in a microvm locally with delegated auth or proxies to avoid it having greater access than granted.
I run it in bwrap so, even if I'm running on Linux, I don't pay the cost of some layered file system and building the docker image. I mount some directories read only, the project repos read write. A VM would provide more isolation but it's a matter of tradeoffs.
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.
Iām kinda surprised Anthropic doesnāt do this by default. Asking permission meant what felt like near-constant manual intervention. It almost made a joke of the agentic claim. It also became mostly useless, as the size and complexity of the scripts meant a brief scan wasnāt likely to find anything anyway. Yet they persisted with it for so long.
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.
This is exactly how my employer runs Claude. It gets r/w to the cwd and read only access to a bunch of whitelisted nfs. All web access goes through a proxy where internal resources are whitelisted
Proxy also lets you bootstrap auth tokens at proxy layer without giving clause access to the auth identity. Greatly limiting the exfil risk.
More than 10 million developers use Claude just fine without VMs or proxies.
The approach is hardly insane, even if you personally prefer additional safeguards.
10 millions developers doing something stupid does not make it right!
It's not stupid if it works and the supposed insane risk never manifests.
Imagine that I am working at the AI company, and my friend has some bone to pick with you. My friend asks me to ask your AI agent to put some unsafe photographs/videos in your computer and do what ever necessary so that it looks like you put those files there.
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...
Tell that to everyone whose agents posted their secrets to GitHub.
Hah, I normally run it in a docker container myself, and only mount the project directory. Anything else it needs, I copy in for it, or occasionally I'll ask it to write an rsync.sh that I can run to bring in the stuff from outside.
Or how it loves using ; to chain commands so that even if the first part fails to run it just moves on the execute the rest, wasting time and being potentially dangerous. I have caught so many of them myself and stopped tasks manually -- what is it doing when it's obvious tests already failed in the previous step?
Their "auto mode rules", meant as additional rules described in natural language to adjust auto mode because, doesn't even help. I have to add a PreToolUse hook to stop that.
Yeah I have a whole ongoing thread with Claude where I paste in screenshots of all the bash prompts auto mode is triggering asking me to allow them. After about two weeks of doing this and having it update its settings.json permissions or showing me which lines to update, its finally able to complete most (inherently safe, low risk) tasks without user intervention.
This still presumably happens in auto mode as it asks for sensitive commands (and the default is "always allow," which saves it)
Yeah good catch. Thinking through what we can do to improve this (ideas welcome).
I would love if Auto Mode, instead of instantly denying the command, had an option to go into an "assisted manual review" interface where the command was explained in depth (perhaps by an adversarial review agent) and the user asked for their input on whether this command is OK. Perhaps needing a detailed response instead of a simple Yes/No, e.g. so the agent understands if there are compensating controls for the risk.
The UI/UX needs to offer editing. Currently the prompt is either accept once, accept always with the given filter, or deny. If the command is a 500 character long bash command, with an rm -rf $S/foo in the middle, and we just hope $S is defined, I don't really have good options other than "I hope my backups work".
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?
Is this maybe a mistaken abstraction?
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.
Two modifications I've made that help:
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.
> Thinking through what we can do to improve this (ideas welcome).
$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.
As a Claude Code user I'm very glad to see Boris and other devs asking for our feedback and advice. That's how you make good products, and should be welcome on HN.
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")
Putting aside the rest of your comment, this
> 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.
I'm completely dumfounded.
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).
Think of it as an informal interview. If you come up with a brilliant idea that no one there was able to communicate effectively, what are the chances they're not going to offer you a job or at least a chance to interview?
Only to lay me off next year after the IPO, no thanks.
So developers who get paid more than $X,XXX,XXX per year don't need to pay attention to their customers. Got it.
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?
How is that a good catch? Itās literally in the article.
Along with how Claude checks it in.
Not optimizing for eyes free coding, versus hands free, would be a welcomed change. It's hard to take the p(doom) worry seriously when such unsafe development practices are prognosticated from Anthropic employees
Eyes free always wins over hands free in the long term. Hands free does not scale (optimize) past the 2023ā2025 human-in-the-loop coding. It has known problems, basically boiling down to human error rate is higher than machine error rate, and the latter reduces with better models. I am incredibly happy that the era of human approval is no longer considered viable by a majority (most of us knew that for years, but reality diffuses slowly in many corporate environments.) This does not mean there isnāt work left to be done, but eyes free is the right focus.
I feel lucky to work in an environment where the sheer amount of code we need to produce is not the bottleneck, so it is actually possible to build the stuff we need while also maintaining understanding and oversight. We do not read all code but work on finding a balance. Many times, the code you do not have to write at all is the best.
It is certainly possible also for us to produce so much code that all hope of understanding and human in the loop is practically gone, but as i wrote this is not the bottleneck and so doing it would the wrong choice.
If you work somewhere where every additional line of code is a positive, I understand if you take this more radical approach of just letting the machine make all decisions.
I have very serious doubts, the errors are not in the same category, transformers are fundamentally limited.
Eyes free is the wrong focus, it will do more short term damage to society, while being impossible at scale. But I understand there are a bunch of valley types who want to completely obviate humans for whatever reason, it's an alternate reality they live in.
Here's the thing, society will revolt against these people, they already gave the first warning shots. This HN submission is a story about another person leaving the products of a company engaging in eyes free practices. You wouldn't want your lawyers and doctors doing that, why software developers then?
> human approval is no longer considered viable by a majority
Where do you see data that the majority believe this? From what I can see it is a shrinking minority as we move beyond peak hype.
You are the one being paid millions to solve this, solve it.
Boris, love Claude code and similar harnesses. This is a modality problem. Set up a secure mode. The harness should manage the secrets injection at the tool level, and the agent should be sandboxed and never see them. The agent sees the manifest of available tools and are wired up and have enough instruction about how to use and how to set up. Similarly permissions should be scoped to opt in folders.
That is some unsavory buck passing. Virtually anyone that didn't ask claude to create the project can leak passwords, with 1,122 known customers that have been impacted. Whether it is standard or not is irrelevant, it is part of existing functionality and entirely foreseeable. I'd expect any company worth the opportunity for trust to clearly own the mistake.
It's the anthropic way lol. "Working as designed"
All issues have already been fixed.
No?
All issues will be fixed today.
No?
It's early days, the models will improve and fix all issues.
We are: at the point where agi has been achieved so if you haven't bought into it you must do so.
If you have bought it and have problems you aren't spending enough in it to fix them.
Then finally, if you did spend enough money, you really haven't, but the problems you have are not anthropics problems even when they are. Spend more money and do free advertising for the company anyways.
Committing `.claude` is at least as dumb as committing `.keys`, so I don't think this is really in-scope
If you know it's there. It gets created on the fly when it is needed, so unless you know that is possible and needs to be gitignored, it could easily slip by.
Do you not review before committing/pushing?
Saying a professional software developer is responsible for not committing secrets is reasonable. That said, these tool chains all seem to condition developers to offload much of that diligence to the tooling itself, which makes catching mistakes harder because youāre not as used to scanning for them. Secrets files have always been foot guns, and with automation-borne complacence, and vibe coders that donāt understand the problem, I imagine these things will become even more common.
This did not impact me. But if using a tool means that secrets can randomly appear in my project, then I am using the wrong tool.
Correct stance.
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!ā
Oh no, I moved all that manual tedious boring loser mentality stuff to the agent. Now Claude does it for me, and no strangely enough Claude didnāt tell me there was a problem!
In these cases they probably just blindly committed everything themselves, if you asked Claude to review the uncommitted changes and do the commit itself it probably would have flagged this.
> 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.
What do you make of that part of the article?
Like I said in my comment that you replied to they likely flagged it and then the user just told it to continue anyways.
It's gitignored by default.
The default of who or what ? Git ignore is empty "by default", inexistant even
When Claude generates the file, it also generates a .gitignore for it or fills in the existing one.
If this is the intended behavior, a quick search of github and the article's findings seem to suggest it doesn't work.
So you just routinely commit everything in the project, without looking at what it is?
My coworkers seem to
It is only the .local files within .claude that can't be committed. We have .claude committed in multiple repos to include repo-specific skills/hooks/permissions.
Hmm.
Dumb if you donāt turn on auto-mode, dumb if auto-mode commits .claude.
No way to hold it right I guess?
If you have stuff in your tree that's not part of your project's code, you're already dumb.
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.
I and other colleagues have been struggling with auto mode refusing perfectly safe commands in our environment, so we frequently find ourselves switching to the other modes to handhold Claude Code into perfectly safe things like triggering deterministic and guardrailed CI/CD pipelines or read-only queries of production data. Auto mode seems overtuned for caution around deployment and production, which is a regression from how useful Claude Code was for operations around June/July. Until that's improved, permission rules are incredibly important to our workflows.
Yeah, by default we err on the side of caution. That said, the auto mode classifier is fully customizable based on your teamās usage. Two ways to tune it:
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.
For some reason claude code hates using the read/write/grep tools and defaults to complex sed, awk, grep Bash:* runs which results in always consistently ignoring auto mode due to the classifier not knowing what to do with a 10-line long bash pipe instead of a read + pre/post read and write hooks being ignored and not firing, what is up with that?
I don't understand this either, it makes commands really hard to parse. It seems like 90% of what claude does could be going through some mcp tool that could be easily sandboxed instead of bash gibberish.
If it was human approval ? Read("./file.name") then Bash("docker compose run unit-tests"), sure, I can read that fine !
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.
Yeah I agree, I didn't used to feel approval fatigue but lately the huge bash chains are giving it to me. I haven't even tried auto mode. I'm just sure it has some definition of "safe" that does not align with my own.
I'm not sure when claude started preferring huge bash chains but auto mode tends to decline most of them and drop to a permission prompt -- getting rid of the use of auto mode -- because it refuses to handle anything chained with expansions, variables or similar items
I use a hook to deny attempts to invoke `grep /` and `find /`, even as part of a complex pipeline.
I had claude write a hook to deny `find /`. It tested it thoroughly. Much later I learned that the hook denied `find /` but allowed everything else that existing permissions denied, like running whatever random python/bash code it wanted without asking.
Auto mode really easily gaslights itself when it runs into a roadblock and starts deviating so far away from its intended goal that I don't let automode run without me reading what it's actually trying.
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.
You should note that auto-mode is handled by a different session (and likely model) from your actual. There's no road block or deviation or context flooding; all it does is monitor the model actually doing the work and block it from potentially problematic actions (which you can usually override by saying you explicitly give permission for X), nothing more.
The context pollution happens when a denial triggers but the model still keeps attempting the harmful action via alternative avenues. It's got nothing to do with the auto-mode eval model's actual output.
I have never seen that happen before. What I see is a mention that the classifier stopped it from doing X and it then asks for explicit permission or gives me the command to run myself.
> perfectly safe things like triggering deterministic and guardrailed CI/CD pipelines or read-only queries of production data
I... question whether the second one is perfectly safe.
Suggest adding it to ~/.config/git/ignore
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
I also use global ignore, but I think the key is to keep secrets out of commands. I store mine in .dev.vars, which Wrangler reads automatically. For production, I use wrangler secret put and enter them myself. I also told Claude to never read that file.
> and teach Claude to not git add .
It already doesn't do this. This is from users committing the `.claude` directory themselves.
GitHub charges an arm and a leg for this service. Before, they would take request to delete committed secrets, now they simply refuse, because they want to force you to buy the overpriced Advanced Security.
Which is odd because my agents are hyper aware of scrubbing. It even caught data from the database migration that wasnāt scrubbed correctly even in a private repo. Dozens of data segments are stored locally and Iām warned when I slip up in commits. Something made mine hyper aware of security.
Offtopic: The new fullscreen renderer is a nice change. It fixes some issues inherent to rewriting terminal history that the non-fullscreen mode relied on. This is a very welcome improvement. Although I should probably switch to the Claude GUI app anyway. It probably has all features from Claude Code by now.
> Permission rules are old hat. Everyone should be using auto mode instead
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.
I appreciate you getting communication out in front of this fast.
> "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.
Thereās a few possible approaches: making sure auto mode catches this, building in basic secret scanning, a few other ideas. Going to prototype a few of these to understand the tradeoffs better before we ship something.
I'm not a CC user myself, so I can't say that I have my head wrapped around exactly how the "yes + don't ask again" flow works. That said- from my (outsider) perspective, saving off the entire tool call [1] and its arguments is very weird. I would expect that the hit-rate following that for similar calls would be very small, which leads me to believe that the list either must be seeded into the auto-reviewer's context, or used in some other similarity-check engine for future calls.
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.
If a given action requires a secret, and you'd like that action to be repeated in the future, how do you expect it to work without said secret included in the save (and without being entangled in secrets management tools)?
Yea good point- constraint of no secrets management tooling kinda makes this impossible. Ideally no action requires a secret in plain text. It would be neat if the harness could bundle its own secret manager, and requests for secrets ("hey I need this api token") are out of band, and placed in the store out of sight of the agent.
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.
> Everyone should be using auto mode instead. It is safer [...]
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.
Isnāt the simple answer shipping a local secret manager with Claude code?
A bit careless but mostly a bad default. One click shouldn't put passwords in files people commit. Anthropic should fix it.
> Everyone should be using auto mode instead. It is safer and ...
Okay, sorry, I am out. It's too beautiful a day to have silly arguments.
Great advice, hope it gets to more people
Arenāt you guys going to be one of the only two software developers employees in the nearest future? And autogenerate all software?
Then you can have it your way :))
I guess "you're holding it wrong" is a PR strategy now.
Coding is solved. Bugs not solved yet. Fix incoming
Auto mode should be used by default? Is this the same mode that led to the Anthropic article discussing unintended model actions?
Ref: https://www.anthropic.com/research/investigating-unintended-...
No thanks.
> but we are looking into what we can do to prevent this.
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?
Shouldn't even need to ask; the Basilisk should simply realise the problem by itself.
It doesnāt matter if they should stay local, day 1 security best practices say you donāt write secrets to files, ever - especially without you even knowing!
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.
> day 1 security best practices say you donāt write secrets to files
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.
and we can disable those for better alternatives. npm executes arbitrary code based on what the package said, obviously bad
claude unleashed on an organization is a whole other beast.
Can we take your responses here to represent your employer's position on this issue?
No, they're just an agent of their employer, the employer is responsible.
Boris is the "Head of Claude Code", so I think we can do so, yes
> 2. Permission rules are old hat. Everyone should be using auto mode instead. It is safer
Instead of telling people they're holding it wrong, make it safe to be held however they could hold it.
$19/user/month for secret scrubbing? What a rip off
Use this instead for free https://github.com/awslabs/git-secrets
> Claude Code reads settings from four files, and an organization can also deliver managed settings from the claude.ai console. Each source has a scope: the set of people and projects a setting saved in it applies to, whether thatās only you, everyone in a project, or everyone in your organization.
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)
You guys need a pr team. All the communicate from anthropic seems to screw itself somehow...
So ... coding is solved but managing your git repo is not solved?
Wouldnāt it make more sense to put in the user app data directory?
I donāt care how good you guys say auto mode is, Iām not giving your AI full permissions to my machine and the more you try to force AI psychosis onto me the closer I am to moving to something else.
> Permission rules are old hat. Everyone should be using auto mode instead
"you are holding it wrong". No, it's not an excuse. Every mode should work correctly, or should not be selectable.
> .claude/settings.local.json is meant to stay local. This is not a file you should check into source control.
Then don't put it in the fucking tree, you idiots.
No, .gitignore is obviously not enough.
Yeah Boris, if Dario let's you communicate here, it'd help with credibility if the English level would be perfect, it's "it's an old hat", I dgaf if people will hang me for this, I think I am right. My hill and all that.
And to recommend auto made to devs is absolutely crazy.
Have a nice day
I disagree. "Old hat" here is an adjective meaning old-fashioned, not a noun requiring an article.
Can secret scanning be enabled by default?
> 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.
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.
Man. I'd prefer talking to Claude. He wrote the code.
Please, just go borrow from this: https://github.com/hackafterdark/phosphor
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.
Confusing headline. They scanned for repos where people had committed their .claude/ folder and local settings and then scanned those files for commands which contained keys or passwords.
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.
That's the chain, yes. The part people don't expect: the file is created inside the project, and Claude Code only adds it to your global git ignore, not the repo's .gitignore. So a fresh clone or a second machine commits it like any other file. In 539 of the 1,105 repos we traced, a commit co-authored by Claude itself changed the file.
> the file is created inside the project, and Claude Code only adds it to your global git ignore, not the repo's .gitignore. So a fresh clone or a second machine commits it like any other file
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.
Fair, āfresh cloneā was wrong. It happens on a new machine or container without the global ignore, in a copied project folder, or once the file has been committed, since ignore rules donāt apply to tracked files.
Why are you copying instead of git clone?
The new wave of git users (coming from AI) don't know what git is.
I wonder how many of this type are 'senior/principle software engineers' employed by our AI vendor overlords. This situation is the inevitable result of vocal VCs (ahem) poo pooing "age" and "experience" and promoting youth as a 'requirement' starting in the '00s, coupled with these same VCs now attempting to hijack an entire industry to run on their obviously immature and buggy and frankly possibly dangerous products.
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.
In that case what relevance does the gitignore file have at all?
That doesnāt make sense. I use my own global git ignore all the time because there are files that only I produce that I definitely donāt want committed (flycheck looking at you). A fresh clone wouldnāt contain these files because they are not committed in the first place. You will have to use a non-git transport mechanism to transfer the repo without also transferring your global git ignore.
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.
They're probably mostly just random solo people who barely even know what git is. This---that people who don't know how to code can code now--is the whole thing that AI companies love to advertise, and it's true. But it also means that tools need to stop people from doing stupid things, because they won't know that the things they are doing are stupid.
It's a disgrace that the parent comment was flagged. My vouching has undone that but it's likely to be flagged again.
It's fully AI generated. Please don't vouch for comments that don't have human input, it's against the rules:
> 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
The author of this comment is also the one who submitted and authored the article being discussed.
No matter whether it's AI generated (I can't tell) or correct (it's not), it makes no sense to flag the response by the author.
> It's fully AI generated
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.
All of their comments were auto flagged from the moment they were posted. Must have triggered an LLM detector or spam detector.
It's AI slop. If what it says is actually true, hopefully a human will post it.
I'm super paranoid about the level of access AI agents have. At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.
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
> At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.
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.
Of course, if it's possible to use deterministic automation, I ask it to set up scripts. But in a lot of cases the task is not deterministic. And even when it is, I still need to safely deal with the credentials. Examples of some tasks I use it for:
- 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)
I'm skeptical of how "super paranoid" you actually are. This doesn't sound super paranoid.
For instance: that's a ton of surface area. Did you have your AI agent decide which endpoint is destructive or did you manually do this?
For instance: has this classification been wrong?
I ask this because I've used a similar thing before and it failed in the ways I've named.
This setup also permits your agent to exfiltrate enormously sensitive data (website gives the example of QuickBooks invoices and Cloudflare config) without your involvement.
The agent doesn't decide which endpoints are destructive, you do. That's the point. It's not allowed to do anything that you don't explicitly grant permission for.
And yes, it has tried to make bad requests! Which it wasn't able to do because it was either rejected outright or asked me for confirmation and I didn't let it through.
The "surface area" you're talking about is just the coverage of the service APIs, which is there just as a nicety to give a semantic preview of what the request is about to do e.g. we know what a gmail request looks like so we can render a preview of the attachment the agent is sending so you can inspect it. Otherwise you'd have to inspect each http request (which you can always do by using the generic http acl).
I somewhat agree with "exfiltrate enormously sensitive data". The thing I'm paranoid about is catastrophic mistakes that can instantly kill the business e.g. "Oops I sold the domain name". Leaking financials is not great, but also not catastrophic. Deleting all our books would be catastrophic, which the underlying QuickBooks key allows you to do!
But in any case, you can choose your level of paranoia and give exactly the amount of access you're comfortable with. For example, I view read access to emails as catastrophic (must worse than read access to financials), so I don't let it do that.
This is one of the reason why we are building https://runeward.io
Sandbox donāt scale anymore and secrets or confidential files shouldnāt be exposed to frontier models.
This page is like 80% repeating itself
If you post output from AI, please remember to edit before publishing
If the thing is not worth writing by yourself, then it is probably not worth of reading by any humans.
don't edit Ai garbage - make Ai your editor that points out mistakes instead
I assume here you mean "editor" in the traditional sense of someone who draws red lines on your printed draft, rather than a tool you use to make the changes directly... ?
Donāt use LLMs.
I'll do you one better, don't use computers.
Exactly. We can all agree the LLM should use computers for us.
No editing required.
/s because humans probably need it.
Why would you "remember" to edit when you explicitly resorted to AI not to do any of that?
Here is how to solve this:
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
I keep all my creds in a password manager (1Password in my case) and Claude canāt see them - when a cred is needed it runs a script that calls the op CLI and I tap my fingerprint for access. Sometimes I need to do it a bunch of times for complex operations, but itās worth it.
I refuse to use op cli because of the absolutely bunkers security model thatās a wontfix:
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 read up and that vuln and itās not the behavior I see. Any read operation to any key in any vault requires auth. Even if the vault is āopenā it still asks me every time.
I think I remember a Bitwarden CLI supply chain vulnerability a few months ago?
https://news.ycombinator.com/item?id=50365442
This seems like a gh issue as well as Claude abusing it. Why should I be able to get the token for GitHub through this call without further authorization?
This may not be a popular answer here, but it works as expected. Basic security hygiene means that you use password manager CLI, SSH agent, at worst temporary git-ignored env files, so that the secrets would never appear in the command line and you would never pass them to Claude. And you git-ignore any local settings by default, to prevent accidental leaks. It is not hard thing to learn, many juniors I interviewed know this. Developers who like to shoot themselves in the legs should pay the price. People who hire careless workers and do not put them in compliant environment should pay the price too.
More and more, I want a hard sandbox on these. For those of a similar security mindset, how are you sandboxing?
This doesnāt seem like the right way to use secrets with an AI agent, in general.
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.
Was reported as BUG on Dec 5, 2025 to Anthropic and automaticaly closed.
https://github.com/anthropics/claude-code/issues/13106
Why does git even allow easy hidden file adding? It should be hard to add a .folder so noobs won't do that.
From my point the best way is to give the AI all the permissions every thing that he needs to not stop on the middle of his work and after he done from the project you should change all the secrets api's, database whatever and by that you will be on the safe side.
please dont forget basic operational security when using LLMs. they dont do everything for you. you can ask them to do all sorts of stuff, that doesnt mean you should.
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.
The problem is LLMs marketed as a replacement for professionals (who know something about OpSec among other stuff). Internet is full of stories about apps vibecoded by people without IT background. They would not even understand whatās the problem here, for them itās all magic.
This is an issue because it is popular, not because it is novel.
Review your code before committing. Do code reviews on PRs.
Mind boggling that supposed professionals in this thread will blame Claude and suggest a 100 different third party tools instead of reviewing code committed to a public repository.
Thereās one (wrong) reason to suggest that: the developers are just another trust layer between business objectives and business users, and there are affected third parties who do not have a say on how their data is processed. To protect the latter we have to consider how to minimize the risks along the supply chain, including how to reduce the damage from vibe coders. Why the answer is wrong? If safe path exists, the tooling should not be responsible or accountable, but tooling vendors can opt in to improve public safety. In this case safe path exists, Anthropic does reasonably good job to steer to it.
Vibe coders don't review code, even if and when published to a public repo.
This could easily be prevented with credential management tools built specifically for ai agents.
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.
I feel like pointing out, there are quite a few sorts of projects that can be developed without requiring any secrets (at least until publishing time, and that's something you really don't need an LLM to do for you once the process is established).
This is why you ALWAYS run gitleaks as a pre-commit hook, agent or not. It's saved me from myself so many times.
Or am I missing something
> So, it's not necessarily "public", it's simply in the repository, and whether it's actually public or not depends on the repository settings.
Even then, you might not want every developer in your company to have the password to the production SQL database...
Thanks, fair point. Our 1,122 files are all in public repos. In a private repo, only people with access can read it, but "don't ask again" still writes the password into a project file that gets committed, so it spreads with every clone and fork, and goes public if the repo does.
According to Claude docs, settings.local.json isn't to be committed. This is just people being the usual sloppy with secrets in repos, not something particular to Claude or AI in general.
But the whole point of Claude Code is that software production is a solved problem accessible to anyone.
here's what they look like btw https://github.com/Marius0G/iDrip/blob/2d79c54fb22025aaa8cf6...
I mean it'd be crazy if this worked:
https://github.com/search?q=path%3A**%2F.claude%2F*.json+CLI...
oh look..
The first extension I add to any coding agent is one that redacts or rejects any read/write of a secret or credential or credential file. It's annoying, and the agent can work around it, but better to add a weak guardrail than none at all. Best is to not give it access to any secrets, but that's not always possible.
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
This is also an example of how someone's personal settings don't belong in a source code repo at all.
I find it pretty annoying when someone commits their harness specific files into a repo - put that stuff under $HOME/.claude/
To be fair, things like AGENTS.md aren't supposed to contain secrets, and are helpful to publish for OSS developers who want agentically-written third-party contributions to follow certain rules.
"git add . " considered harmful
From TFA:
> 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.
always was
It's the plaintext secrets that are harmful.
Yeah like... you are writing passwords on the command line? All of these are already leaking into your .bash_history or similar so what are you doing my dude...
Iāve set a hard rule for my agents to ānever add all files, never commit all files, always reference the specific files you are adding or committingā
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.
I just mount .git read-only in my sandbox. That way I don't need to worry about it violating my safeguards.
This just in checking your secrets into source control exposes your secrets!
People chose to upload a file containing their password and make it publicly accessible, I don't see a problem here.
The article reads as though an LLM wrote it
The solution, ironically, is always run in YOLO mode
Relatable lol. Personal privacy and security goes out the window when you go full Claude
The irony that the article is written with Claudeā¦
Claude did the research too, Opus 5.5 specifically. It took the findings surprisingly well.
What do you mean by ātookā? Is the implication that Claude would be, likeā¦ embarrassed somehow?
Just a joke
Plain text secrets? Super rookie mistake!
I still don't understand why people are using GitHub for their vibecoded projects. Just install git locally on your own NAS and control it there. What a weird fetish to publish online.
There are a lot of legitimate reasons to have a public github/gitlab/whatever account that is not self hosted.
Care to list some?
One of the biggest for me would be sharing the repo/working together without exposing my server/NAS to the public.
Thereās a reason why private and public repo exists.
it's 2026. surely you're aware of ci/cd? static page hosting? package hosting? the many other services that github offers beyond hosted git?
I am using my own Git system with encrypted cloud sync and host over 30 web apps with this system. Many static websites, too. Never needed to use git in my life, except for a few cringy company projects that I was forced to be involved in.
cool man
> I still don't understand why people are using GitHub for their vibecoded projects.
For all the same reasons they used it pre-LLM for hand-written toy projects.
To post on linkedin and to brag about all your projects and active github account when applying to jobs.
You think people that vibe code have a NAS?
Yes there is very likely a large overlap
If you really need to commit private files to GitHub, use Turbocrypt https://github.com/jedisct1/turbocrypt/blob/main/docs/git.md
Or git-crypt, which has been around for over a decade: https://github.com/agwa/git-crypt
Once again, devs shocked when random number generator has unpredictable results.
Vibe coders in open source proudly don't read the (slop)code and place all their agents in autonomous loops without them knowing that Claude leaked their passwords and environment variables on GitHub.
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.
Devs have been leaking secrets in public repos a long time before now. Nothing new here, except there are now more with dev power, which statistically means more leakage.
Thatās ridiculously overblown rhetoric. Claude Code didnāt publish these secrets, the users did by committing their Claude Code settings to public repos.
Same thing could/would happen with an open source harness.
From TFA:
> 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?
Nothing stops someone from committing secrets to public repos, with or without AI. Unless guardrails are put in place that scans repos before push, and only people already wary of secrets leaking would setup said guardrails in the first place.
The file is .gitignored if Claude creates it - any commits by Claude would be due to someone overriding that or creating it themselves incorrectly.
None of this has anything to do with open vs. closed source.
Of course an open source harness can put secrets into a commit.
Humans do it!