Yet another Hacker News

Claude Code's "Don't Ask Again" exposes passwords in 1,122 public GitHub files

92 points shmulc 2 hours ago 71 comments

qezz 2 hours ago | parent

  > 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.

Or am I missing something

shmulc 2 hours ago | parent

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.

mschuster91 1 hour ago | parent

> So, it's not necessarily "public", it's simply in the repository, and whether it's actually public or not depends on the repository settings.

Even then, you might not want every developer in your company to have the password to the production SQL database...

Aurornis 2 hours ago | parent

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.

shmulc 2 hours ago | parent

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.

cassianoleal 1 hour ago | parent

It's a disgrace that the parent comment was flagged. My vouching has undone that but it's likely to be flagged again.

Aurornis 1 hour ago | parent

All of their comments were auto flagged from the moment they were posted. Must have triggered an LLM detector or spam detector.

kragen 21 minutes ago | parent

It's AI slop. If what it says is actually true, hopefully a human will post it.

kccqzy 37 minutes ago | parent

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.

Aurornis 19 minutes ago | parent

> 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.

lacoolj 2 hours ago | parent

This page is like 80% repeating itself

If you post output from AI, please remember to edit before publishing

NooneAtAll5 2 hours ago | parent

don't edit Ai garbage - make Ai your editor that points out mistakes instead

nicce 1 hour ago | parent

If the thing is not worth writing by yourself, then it is probably not worth of reading by any humans.

solyin 30 minutes ago | parent

What's it like being a stoichastic human- parrot?

rvz 2 hours ago | parent

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.

happyopossum 2 hours ago | parent

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.

cassianoleal 1 hour ago | parent

From TFA:

> Often Claude commits the file itself. In 539 of the 1,105 repos with a real secret that we traced, a commit co-authored by Claude changed the file. Those commits name every recent model, from Sonnet 4.5 to Opus 5.5.

Could open source harnesses do that? Sure, if they were programmed in a similar fashion as Claude Code. Do you have any evidence of it happening?

ceejayoz 59 minutes ago | parent

Of course an open source harness can put secrets into a commit.

Humans do it!

skeledrew 58 minutes ago | parent

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.

happyopossum 53 minutes ago | parent

The file is .gitignored if Claude creates it - any commits by Claude would be due to someone overriding that or creating it themselves incorrectly.

None of this has anything to do with open vs. closed source.

skeledrew 1 hour ago | parent

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.

jedisct1 2 hours ago | parent

If you really need to commit private files to GitHub, use Turbocrypt https://github.com/jedisct1/turbocrypt/blob/main/docs/git.md

Groxx 1 hour ago | parent

Or git-crypt, which has been around for over a decade: https://github.com/agwa/git-crypt

bcherny 2 hours ago | parent

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)

agentdev001 2 hours ago | parent

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.

bcherny 2 hours ago | parent

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.

agentdev001 1 hour ago | parent

I'm not a CC user myself, so I can't say that I have my head wrapped around exactly how the "yes + don't ask again" flow works. That said- from my (outsider) perspective, saving off the entire tool call [1] and its arguments is very weird. I would expect that the hit-rate following that for similar calls would be very small, which leads me to believe that the list either must be seeded into the auto-reviewer's context, or used in some other similarity-check engine for future calls.

If we've already crossed the bridge to being confident in a non-deterministic reviewer for auto-mode, then, I see no obvious reason as to why we couldn't have the proposed rules be generated by a model. If that were reality, then- all rules placed in settings.local could be secretless, with the confidence of whatever model we tell 'make sure the rule does not contain secret material, consider its destination as potentially public'.

[1] https://code.claude.com/docs/en/permissions#wildcard-pattern... AFAICT, CC will either save off a prefix+wildcard rule, or exact command. Sounds like the former is likely not the cause of the problem here.

skeledrew 52 minutes ago | parent

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)?

markasoftware 2 hours ago | parent

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"

bcherny 2 hours ago | parent

Auto mode is significantly safer than manual approval in practice. Details about the engineering approach and how we tested whether it is safer here: https://claude.com/resources/articles/auto-mode-default-in-c....

ceejayoz 1 hour ago | parent

Is that because auto mode is good, or because the manual approval system sucks?

bcherny 1 hour ago | parent

The blog post has more detail, but tldr is humans make mistakes that automation can catch.

ceejayoz 1 hour ago | parent

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.

gsnedders 1 hour ago | parent

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.

bcherny 1 hour ago | parent

Will look into exposing that in hooks.

Ultimately, the threat model here is: human has to approve a lot of commands, so gets tired and accidentally approves a command they shouldn’t have. We spent a significant amount of effort to build a richer permission system, allow configuration at multiple levels, use static analysis to detect dangerous and safe commands, monitor the model to detect and block prompt injection at the inference layer, etc. Some of these components we rewrote and red teamed dozens of times. Our conclusion was that despite all of this work, in practice the threat model is that human attention is limited and that that a different approach performs an order of magnitude better in practice.

aftbit 25 minutes ago | parent

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.

kragen 24 minutes ago | parent

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.

wonnage 19 minutes ago | parent

this is not a serious proposal

kragen 12 minutes ago | parent

Not only is it a serious proposal, it's been used in practice in every airport X-ray baggage scanner for decades, where it's called Threat Image Projection (TIP): https://www.xscann.com/products-HiTipPlus.html and it's actually a regulatory requirement in that context in a number of countries: https://caainternational.com/course/threat-image-projection-...

ceejayoz 3 minutes ago | parent

Yes, but you can require it in such a situation, as they're subordinates who have to follow policy or lose their jobs.

cozzyd 1 hour ago | parent

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?

eterm 1 hour ago | parent

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".

knollimar 42 minutes ago | parent

I hate this condescension by Claude. It doubles down in such a bad faith way.

markasoftware 1 hour ago | parent

No its not generally safer. It depends on who is doing the approving, the task being completed etc.

bulder 36 minutes ago | parent

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.

wyager 40 minutes ago | parent

"My personal security model can't represent this, therefore it's not secure"

bluebands 2 hours ago | parent

This still presumably happens in auto mode as it asks for sensitive commands (and the default is "always allow," which saves it)

bcherny 2 hours ago | parent

Yeah good catch. Thinking through what we can do to improve this (ideas welcome).

80fj0348i 1 hour ago | parent

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.

mococa 2 hours ago | parent

[flagged]

dang 2 hours ago | parent

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.

https://news.ycombinator.com/newsguidelines.html

80fj0348i 2 hours ago | parent

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.

bcherny 1 hour ago | parent

Yeah, by default we err on the side of caution. That said, the auto mode classifier is fully customizable based on your team’s usage. Two ways to tune it:

1. After a command is blocked, run /permissions to retry and allow it going forward

2. More deeply configure the classifier itself: https://code.claude.com/docs/en/auto-mode-config

We are working on making these easier and more automated.

written-beyond 1 hour ago | parent

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.

skeledrew 42 minutes ago | parent

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.

bulder 17 minutes ago | parent

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.

kay_o 40 minutes ago | parent

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?

dcrazy 14 minutes ago | parent

I use a hook to deny attempts to invoke `grep /` and `find /`, even as part of a complex pipeline.

deadbunny 1 hour ago | parent

This must be satire.

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

stogot 28 minutes ago | parent

$19/user/month for secret scrubbing? What a rip off

Use this instead for free https://github.com/awslabs/git-secrets

cerved 10 minutes ago | parent

Suggest adding it to ~/.config/git/ignore

and teach Claude to not git add .

While we're at it, maybe we can also discourage the spurious use of -f for rm -- me personal pet peave

GeoAtreides 2 hours ago | parent

"git add . " considered harmful

cassianoleal 1 hour ago | parent

From TFA:

hleszek 1 hour ago | parent

always was

polarsanel 16 minutes ago | parent

It's the plaintext secrets that are harmful.

flufluflufluffy 2 hours ago | parent

This just in checking your secrets into source control exposes your secrets!

binarymax 1 hour ago | parent

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.

GaryBluto 1 hour ago | parent

People chose to upload a file containing their password and make it publicly accessible, I don't see a problem here.

skeledrew 1 hour ago | parent

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.

fuckaiagi 9 minutes ago | parent

Why this fucking crapware is leaking secrets? It is not AGI yet?