> 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.
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.
I think solyin is trying to imply that the anti-AI sentiment is as formulaic as any hopped-up markov chain. So perhaps a better way of rephrasing their question is "What's it like to be meat?"
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.
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)
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.
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 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.
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 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.
> Everyone should be using auto mode instead. It is safer
This is an absolutely crazy statement without bundling proper sandboxing. Even the `/sandbox`ing that is provided was completely broken when I first and last tried it, not working as documented whatsoever. Of course, my human-created issue pointing it out was completely ignored, along with all the other GH issues that don't make HN front.
Nobody should be using auto mode outside of environment they'd be happy with '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.
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.
That is some unsavory buck passing. Virtually anyone that didn't ask claude to create the project can leak passwords this way with existing functionality, whether it is standard or not, and it is entirely foreseeable. I'd expect any company worth the opportunity for trust to clearly own the mistake.
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.
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.
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.
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.
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.
> 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.
> 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.
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)
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.
> 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)
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.
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.
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.
Yeah. Boris, you and Anthropic need to stop pretending "just trust me bro" is a security architecture. It's a self-aggrandizement architecture.
Claude will have auto mode turned on whenever she's locked down on a meticulously isolated machine, with carefully managed proxies that I control deciding (and logging) which agent with which access patterns is allowed to access which resources, locally and on the network. Anything else is malpractice.
My opinions do not represent those of my erstwhile employer NVIDIA Corporation.
It's to help people realise that your advice might be wrong and they won't have any recourse against you for reparations - but in many jurisdictions, it's actually illegal to give legal advice if you're not registered e.g. regarding immigration.
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.
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.
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...
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
> 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 batch 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.
> 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 thing.
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.
Cool, I was always curious why do you build safety classifiers and confirm prompts that are not 100% reliable when you could just run all AI tools in a VM?
Obviously if it is company's machine, I am ok with running AI tools directly without any restrictions (because it is not my problem if they destroy it), but never on my personal device.
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.
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.
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.
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 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'.
> 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.
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.
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.
>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 respected sandboxing (even without the user bothering with custom sandboxing themselves) on top of auto mode.
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.
> 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 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?
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.
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.
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.
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.
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 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.
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
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.
246 comments
[ 0.21 ms ] story [ 31.8 ms ] threadOr am I missing something
Even then, you might not want every developer in your company to have the password to the production SQL database...
So pressing “Don’t Ask Again” by itself doesn’t expose passwords by itself. If you commit your local Claude settings and in those settings you have manually approved commands containing secrets directly in the command and then you publish the repo, that’s exposed.
If you post output from AI, please remember to edit before publishing
so your question is “What’s it like to be a meat proxy?” which might be taken as trolling
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.
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)
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
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... question whether the second one is perfectly safe.
1. We store any of your secrets we find in plaintext please don't commit them with `git add -A`, don't worry Claude will do this for you.
2. Just let us run arbitrary commands on your laptop, it's totally safe (for us)
3. Fuck you, it's not our problem
https://news.ycombinator.com/newsguidelines.html
Use this instead for free https://github.com/awslabs/git-secrets
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.
Tbqh its a bit bad ux. I wish you guys let us use other harnesses with the sub
This is an absolutely crazy statement without bundling proper sandboxing. Even the `/sandbox`ing that is provided was completely broken when I first and last tried it, not working as documented whatsoever. Of course, my human-created issue pointing it out was completely ignored, along with all the other GH issues that don't make HN front.
Nobody should be using auto mode outside of environment they'd be happy with 'everything is approved' mode too.
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.
This is such a typical blame the user response. You realize if I’m a sysadmin managing fleets of machines, this is an actual wake up in a cold sweat nightmare, even if those files never leave disk? In the past it was less a big deal, way bigger now that your machine god will just download packages and libs that have upstream malware that aggressively scans the file system for stuff like this. guess where it’s going to look first?
have more humility. jesus.
If only tools, including major ones, actually did that. Plenty of the biggest package managers in the world still write API keys in plain text to files. uv and npm are two of them.
claude unleashed on an organization is a whole other beast.
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.
Dumb if you don’t turn on auto-mode, dumb if auto-mode commits .claude.
No way to hold it right I guess?
No?
All issues will be fixed today.
No?
It's early days, the models will improve and fix all issues.
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.
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?
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.
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.
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.
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 that you're trying to make Claude Code safer, but you've been doing it the wrong way.
The agent should NOT have ANY access to:
- Your ENV
- Your homedir
- The network at large
- ANY other directory on your system
- No, not even your workdir.
The only safe way to use an agent is COMPLETELY isolated by a container or VM, using git semantics to extract its output.
But even that wouldn't be enough because LLMs are nondeterministic, and these kinds of issues are the inevitable results.
Only a mechanical, deterministic failsafe can protect you from it.
Can you point me to the CC source code?
Regardless, It's kinda silly to keep the harness code hidden. There aren't any valuable secrets in there.
But there are rules & procedures to follow, so...
I also have to trust its “decompilation” is accurate.
Then don't put it in the fucking tree, you idiots.
No, .gitignore is obviously not enough.
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 are holding it wrong". No, it's not an excuse. Every mode should work correctly, or should not be selectable.
Claude will have auto mode turned on whenever she's locked down on a meticulously isolated machine, with carefully managed proxies that I control deciding (and logging) which agent with which access patterns is allowed to access which resources, locally and on the network. Anything else is malpractice.
My opinions do not represent those of my erstwhile employer NVIDIA Corporation.
BTW, I just checked and my .gitignore files ignore .claude
Claude and any other program in my laptop could upload it anyway to any attacker controlled server. It's the usual threat analysis: who you want to defend against, what and the tradeoffs between cost of the defense and probability of the attack. Auto mode of not auto mode is in the cost of defense part IMHO.
The approach is hardly insane, even if you personally prefer additional safeguards.
Then my friends tips off the cops. And your life disappears! Gone!
And you didn't get a chance to share your story because I don't think you ll have wifi where you would be going, and frankly you are too clueless to imagine your AI agent doing something like that...
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.
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.
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.
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.
Of course, that only helps if you’re familiar with ruby. And the agents sometimes still choose Bash regardless of the instruction.
Though I think this is largely transitory, we are already in a place with the harnesses and models like Opus 5.5 that the kinds of work you are doing involve so much that vetting everything manually is probably less efficient than setup up access control on the prod routes or dangerous resources.
I'm typically giving tasks that invlude multiple actual repositories and systems at the same time.
That said, I've also seen problems from complicated bash calls with Opus 5.5 on xhigh. Occasionally git push hangs and it believes it's waiting for an hour for git hooks.
The actual reason apparently was that it incorrectly piped git into grep, resulting in a deadlocked command.
This is not a good reason. Models can batch tool calls, which a smart harness will process all at once without starting a new turn. I see it in Zed all the time. In fact, Zed processes batched tool calls concurrently, which can be faster than a chain of Bash commands, and failure of one part does not cause failure of subsequent parts chained with `&&`. This approach is token neutral and easier to understand.
Are you sure? I read its proposed commands (auto mode is hard off for me), and mostly it seems to string together fairly simple info gathering commands (ie grep's, echo's, that kind of thing).
I don't tend to have it write much code recently though, instead I'm having it investigate config files/code bases, and that kind of thing.
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.
Obviously if it is company's machine, I am ok with running AI tools directly without any restrictions (because it is not my problem if they destroy it), but never on my personal device.
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.
Ref: https://www.anthropic.com/research/investigating-unintended-...
No thanks.
And to recommend auto made to devs is absolutely crazy.
Have a nice day
Instead of telling people they're holding it wrong, make it safe to be held however they could hold it.
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.
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.
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.
Okay, sorry, I am out. It's too beautiful a day to have silly arguments.
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.
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 respected sandboxing (even without the user bothering with custom sandboxing themselves) on top of auto mode.
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.
Then you can have it your way :))
> 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.
If that’s your approach maybe just mount the entire filesystem read-only, and give the agent a small tmpfs to work with?
It’s easy to not let your agents change anything, that’s not the problem we’re solving here.
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?
For all the same reasons they used it pre-LLM for hand-written toy projects.
The best solution I've been able to come up is using an ephemeral vm (on an isolated network) per task, using --dangerously-skip-permissions so it doesn't bother me. I couple that with an API proxy that lets me restrict the permissions it has to external services. So e.g. where a quickbooks API key gives the holder "god mode" access, the proxy lets the agent do certain read commands without confirmation, but all write endpoints except uploading receipts require confirmation on my phone before they'll be allowed to hit the quickbooks servers. I no longer need to trust that the agent will interpret my readonly wishes correctly.
Tooting my own horn here, but this setup works incredibly well! I've been able to connect dozens of services safely where I absolutely do not trust giving raw, overpowered credentials or oauth integration to the agent directly. I actually just released the API proxy today at https://keycontain.com
Consider reframing. Is the problem really that the task is tedious? Or that it's required? Maybe you should be leaning more on deterministic automations (which the LLM can help set up) rather than LLM-powered ones.
- Research and buy me a domain name for xyz product, set up all of its DNS the way I want for this product, set up email, set up app store submissions including screenshots and description, set up firebase notifications, set up my Google cloud project and any apis I need to enable for this app, deal with app store review feedback.
- Do an audit of my books, make sure every transaction has a receipt uploaded, and make sure the receipt matches the journal entry. Pull statements from all my my bank accounts and reconcile against my books. Fix mistaken transactions with my confirmation.
- Freely push to my source control, but only to specific branch prefixes (surprised that GitHub, gitlab, gitea, etc don't have this built in already). Merge with my confirmation.
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.
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.
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.
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.
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 find it pretty annoying when someone commits their harness specific files into a repo - put that stuff under $HOME/.claude/