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)
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.
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.
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.
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.
> 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
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.
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 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?
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.
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".
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
> 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.
> Everyone should be using auto mode instead. It is safer [...]
This is bullshit.
I'm one of the people who actually read 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.
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.
Please make your substantive points thoughtfully and don't cross into name-calling and haranguing.
When knowledgeable people show up to address concerns on HN, that's good for all of us. We don't need you to like or agree with what they say, but we do need you to follow HN's guidelines.
Threads like this can easily turn into mob dynamics—it has happened before—and when they do, that's bad for all of us.
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.
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.
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
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 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?
> 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.
> 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.
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.
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.
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)
This is called "approval fatigue".
If you think this can't possibly happen to you, you might be in for a surprise. This is an almost textbook case of classic conditioning. You'll find yourself hitting that button faster and faster even while fighting back the urge. So a human is no guaranteed backstop.
This is the scenario that cc auto mode guards against. It cuts down the number of permission prompts to something manageable, so that your fingers don't get trained into clicking 'approve' on 'rm -rf' in the very eyeblink that it appears.
So maybe you feel it doesn't work in theory; but weirdly enough, in practice this particular approach is actually one of the better ones; especially when used in combination with other common sense measures where practical.
With e.g. VM or container sandboxing, we can say things like "If there are no vulnerabilities in the hypervisor or hardware, then the agent can only access these files, these network services, etc". Auto mode doesn't even try to provide any guarantees, so it's impossible to reason about. It amounts to just using the models judgment about what's "malicious" or not, a definition which is subjective, changes model to model, and can be influenced by attacker input.
Empirical evaluations of how many vulnerabilities manual vs auto mode let through are not super meaningful because auto mode changes dramatically with model releases, the type of task being performed, whether the attacker is making targeted attacks designed to bypass auto mode, etc. A security feature cannot rely on these sorts of factors if it's to be taken seriously.
Further, percent of malicious tool calls accepted is a bad metric. It's like measuring the security of ssh in terms of what percent of unauthenticated logins succeed. The only acceptable value is zero. It's pass/fail, not a spectrum. So both auto and manual mode should fail equally here. Further, the set of malicious tool calls admitted in auto mode may not be a subset of those admitted in manual mode.
I think I'd trust the current approver with correctly classifying regular semi-interactive LLM behavior fairly well.
However, if we bring in a hostile adversary that calculus changes, and you'd be right to start thinking about other approaches.
On the other hand, transformers are a surprisingly powerful technology, and I wonder if there wouldn't be ways to train one to several nines reliability under adversarial attack. It seems to have worked in at least one case; though I'd be a bit cautious to extend that conclusion to more cases quite yet.
* https://hackmyclaw.com/ ; https://simonwillison.net/2026/Jun/26/hack-my-ai-assistant/
You do have a bit of a point, though: I’ve run several models in sandboxes with --dangerously-skip-permissions for months; in the full expectation that I'd need to replace a sandbox once in a while. But so far none of the sandboxes have trashed themselves, yet. knock on wood
Auto mode seems like a lighter-weight version of that: fewer local resources, and it can run on the metal if you need cc to help with system work.
Many of the problems when it comes to the manual approval feel like they stem from the expectation of using auto mode in the first place. After all, what's the point of improving the manual approval and safety matching if auto mode is the end all be all, and what's the point of training the model to output commands in a manner that can be parsed by a human if auto mode is always meant to be used? It's very rare for me to not see "command could not be statically analyzed", because the model keeps outputting bash golf.
That is not the niche case, that's the dominant use of models.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
It would be helpful to distinguish between your own opinion on how models ought to be used, compared to how others actually use models.
However I do share your desire for a better manual mode. Auto-mode is both sometimes surprisingly lax, and sometimes too restrictive. Maybe manual mode should inject a reminder "keep your commands as simple one-liners", the same way plan mode injects a reminder that you are in plan mode and don't want any code changes
As it says:
> 5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice
Claude Code never should have prompted to always allow Bash(python:*) or Bash(node:*) — that’s clearly a bad idea, and Anthropic know that (given the references in the article!).
Of course, Bash(python a.py) still isn’t safe if you also allow Write(a.py), because you may as well allow Bash(python:*) at that point, and that’s often practically what people want (“I want to both make edits to the source and then run the test suite”). So maybe the whole permission system is broken to start with — and the actual answer is leaning more heavily on fine-grained sandboxing.
You also, as the article rightfully points out, run into permission fatigue and users blindly hitting allow.
I do still wish you could do more with hooks — outside of auto, I might want to allow a given command via a hook if Claude Code has read access to given file, but there’s no way to query if a given path allows/denies read/write.
Ultimately, the threat model here is: human has to approve a lot of commands, so gets tired and accidentally approves a command they shouldn’t have. We spent a significant amount of effort to build a richer permission system, allow configuration at multiple levels, use static analysis to detect dangerous and safe commands, monitor the model to detect and block prompt injection at the inference layer, etc. Some of these components we rewrote and red teamed dozens of times. Our conclusion was that despite all of this work, in practice the threat model is that human attention is limited and that that a different approach performs an order of magnitude better in practice.
With SOTA agents that’s a real bind, because they’re very likely to find those gaps. Whether they exploit them, close them, or leave them alone then becomes a prompting challenge yet again.
I don't think this means don't sandbox at all. You can prevent a lot of small and medium accidents by locking down or gating access to hidden files, ssh, sudo, etc.
But your sandbox can never be the whole story.
Speaking of really significant things being at risk, it's pretty infuriating that the web-chat Incognito mode can't write and test code locally, and neither the non-Incognito web-chat nor the local Claude Code client can be shielded from the knowledge of my email address and my geolocation. (Even the Incognito mode knows my geolocation.) This gives users no alternative but to put privacy-sensitive information at the disposal of Claude Code, which is far too unreliable to be entrusted with it. It's tempting to attribute this to Anthropic's corporate DNA valuing users' interests at a very low level, but conceivably it's just an oversight, and if I mention it here, it will be corrected in a month or two?
Currently, my assessment is that Claude Code, and in particular the Opus 5.5 model, is head and shoulders above the competition in software development capabilities. Nothing else is even close. But I've seen several small signs like this which suggest that Anthropic, as a company, is maliciously misaligned. So, if Grok, Qwen, GLM, or Astra starts to come anywhere close to being competitive, I'll switch as soon as I can. I imagine that most of your users feel the same way.
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
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.
- 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.
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.
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.
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.
$Trillion AI company asking for ideas from the community whose work they hoovered up to make money, ruin an entire industry and make lifetimes of hard earned skill completely valueless in the span of 2 years.
I've always been into programming as a way to solve problems, and that CC allows us to get more done faster is a good thing.
(Up to the point that we get to RSI and extremely powerful models that we don't know how to align or control. Which I think is uncomfortably soon, and so there's a part of me that says "don't make CC better, it's on the critical path to reaching RSI before we're ready")
> Thinking through what we can do to improve this (ideas welcome)
> $Trillion AI company asking for ideas from the community
indeed always felt very weird to me. $trillion dollar company, with employees bought for as high as $100m, and a whole team/time/internal knowledge/resources/data at their disposal, asking for ideas from random individuals in some public forum? Really? How is this real? Maybe I'm missing the mark here, but it always struck me as odd.
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?
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.
1. After a command is blocked, run /permissions to retry and allow it going forward
2. More deeply configure the classifier itself: https://code.claude.com/docs/en/auto-mode-config
We are working on making these easier and more automated.
As I was reading your post I got another approval request that auto-mode did not understand. It was a single Bash call !!23!! lines tall on a retina mac display with six different variables. If anything this is the cause of approval fatigue and auto mode does nothing helpful when this is every call. I also have in my claude.md and global instructions to use tool calls rather than bash grep/cat/find, which are disregarded.
I frequently hit stop on and auto mode task to prevent it from completely flooding my context with some completely unrelated garbage.
Claude really should push away tasks that end up needing more exploration in worker contexts. That way the workers can maintain a sensible amount of context without pushing the main chat into the dumb region.
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.
This is bullshit.
I'm one of the people who actually read 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.
and teach Claude to not git add .
While we're at it, maybe we can also discourage the spurious use of -f for rm -- me personal pet peave
It already doesn't do this. This is from users committing the `.claude` directory themselves.
Wait, I'm confused. You said yourself coding was solved, surely all you need to do is ask your AI God to come up with an idea, right?
This is such a typical blame the user response. You realize if I’m a sysadmin managing fleets of machines, this is an actual wake up in a cold sweat nightmare, even if those files never leave disk? In the past it was less a big deal, way bigger now that your machine god will just download packages and libs that have upstream malware that aggressively scans the file system for stuff like this. guess where it’s going to look first?
have more humility. jesus.
If only tools, including major ones, actually did that. Plenty of the biggest package managers in the world still write API keys in plain text to files. uv and npm are two of them.
> "but we are looking into what we can do to prevent this"
I would presume that CC's auto-review of tool-call turns would already solve this >99% of the time, no? From my read, any harness-side deterministic solution here would be saving the user from themselves, which seems like a bad pattern. Somewhat dulling the scalpel in my mind.
If we've already crossed the bridge to being confident in a non-deterministic reviewer for auto-mode, then, I see no obvious reason as to why we couldn't have the proposed rules be generated by a model. If that were reality, then- all rules placed in settings.local could be secretless, with the confidence of whatever model we tell 'make sure the rule does not contain secret material, consider its destination as potentially public'.
[1] https://code.claude.com/docs/en/permissions#wildcard-pattern... AFAICT, CC will either save off a prefix+wildcard rule, or exact command. Sounds like the former is likely not the cause of the problem here.
Otherwise you need a broker that can verify chain of trust for the workload, but that's significantly more complexity if you're pitching a harness/app.
Use this instead for free https://github.com/awslabs/git-secrets
When knowledgeable people show up to address concerns on HN, that's good for all of us. We don't need you to like or agree with what they say, but we do need you to follow HN's guidelines.
Threads like this can easily turn into mob dynamics—it has happened before—and when they do, that's bad for all of us.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
So pressing “Don’t Ask Again” by itself doesn’t expose passwords by itself. If you commit your local Claude settings and in those settings you have manually approved commands containing secrets directly in the command and then you publish the repo, that’s exposed.
A fresh clone wouldn’t have the file. This claim doesn't make any sense.
The only way I can see this getting committed is if someone edited their global .gitignore or, more likely, did a whole directory transfer to do a different machine to work on.
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.
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
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.
If you post output from AI, please remember to edit before publishing
so your question is “What’s it like to be a meat proxy?” which might be taken as trolling
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?
Or am I missing something
Even then, you might not want every developer in your company to have the password to the production SQL database...
> Often Claude commits the file itself. In 539 of the 1,105 repos with a real secret that we traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.
They violate it so regularly that my “git” command is now a wrapper, when the agent fucks up and tries to add/commit-all anyway, it now gets a nastygram error chiding it for not following instructions.
This incident would have been caught in an open source harness. This one is closed source malware, and you don't know what Claude Code does internally to behave like this.
Yet another reason why you cannot trust a closed harness.
Same thing could/would happen with an open source harness.
> Often Claude commits the file itself. In 539 of the 1,105 repos with a real secret that we traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.
Could open source harnesses do that? Sure, if they were programmed in a similar fashion as Claude Code. Do you have any evidence of it happening?
None of this has anything to do with open vs. closed source.
Humans do it!