Claude Code's 'Don't Ask Again' File Exposes Passwords and Keys in 1,122 Public Copies on GitHub (thehackernews.com) 23
Be careful with the file .claude/settings.local.json, warns The Hacker News:
Passwords and API keys that developers typed into commands they approved in Claude Code are sitting in public GitHub repositories, where anyone can read them. When a user selects "Yes, and don't ask again," Anthropic's AI coding assistant can save the command, word-for-word, including the secret, in a project settings file. Software security company Apiiro said that 1,122 public copies of that file hold at least one secret, though it did not test whether any still work. One company the researchers notified earlier this week confirmed its key had been live...
Removing [the file] from a project does not undo the leak, because older versions stay in git history and in forks of the repository. The researchers' advice is to rotate first: change every password, token, and key the file has ever held, then clean up...
Claude Code tries to keep the file out of git. The first time it writes the file in a git repository, it adds the file to the user's global git excludes, its settings documentation says. Git on that computer then ignores the file in every repository. That protection stays in one user's git settings on one computer. It does nothing for a file that was already committed, the researchers say. Claude Code never adds the file to the project's own .gitignore, so the protection does not travel with the project. In 539 of the 1,105 repositories the researchers traced, a commit listing Claude as a co-author changed the file. They take this to mean Claude often commits the file itself.
Apiiro's search of public GitHub found 104,185 copies of the file in 103,617 repositories, its research write-up shows. About 1.1% of them, or 1,122 copies, hold at least one secret. Together they hold 1,379 different secrets... ]And "in half of those repositories it had been there for at least 217 days."] More than a third of the secrets open a database directly, including 379 database passwords. Others include 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Among the owners of these files are 63 organizations, mostly software companies of all sizes. The strongest cases include a database vendor's own admin-level cloud key and the owner password of a medical-records database, the researchers say.
Boris Cherny, Anthropic's head of Claude Code, responded to the story in a comment on Hacker News:
"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)"
Cherny also named approaches Anthropic plans to prototype, Apiiro notes in an update, citing Cherny's goal of "making sure auto mode catches this, building in basic secret scanning," and, when a reader noted the same can happen in auto mode when it asks about a sensitive command, answered "good catch."
Claude Code users had already filed a bug report on the issue on August 11, 2025, notes The Hacker News, but "An automated bot closed that report as 'not planned' on January 3, after 60 days without activity."
Three more bug reports were then filed, according to the researchers. "None got a reply from Anthropic, and three were closed automatically as inactive or duplicate."
Removing [the file] from a project does not undo the leak, because older versions stay in git history and in forks of the repository. The researchers' advice is to rotate first: change every password, token, and key the file has ever held, then clean up...
Claude Code tries to keep the file out of git. The first time it writes the file in a git repository, it adds the file to the user's global git excludes, its settings documentation says. Git on that computer then ignores the file in every repository. That protection stays in one user's git settings on one computer. It does nothing for a file that was already committed, the researchers say. Claude Code never adds the file to the project's own .gitignore, so the protection does not travel with the project. In 539 of the 1,105 repositories the researchers traced, a commit listing Claude as a co-author changed the file. They take this to mean Claude often commits the file itself.
Apiiro's search of public GitHub found 104,185 copies of the file in 103,617 repositories, its research write-up shows. About 1.1% of them, or 1,122 copies, hold at least one secret. Together they hold 1,379 different secrets... ]And "in half of those repositories it had been there for at least 217 days."] More than a third of the secrets open a database directly, including 379 database passwords. Others include 43 SSH logins for public servers, 42 tokens for GitHub, GitLab and npm, and 23 AWS keys. Among the owners of these files are 63 organizations, mostly software companies of all sizes. The strongest cases include a database vendor's own admin-level cloud key and the owner password of a medical-records database, the researchers say.
Boris Cherny, Anthropic's head of Claude Code, responded to the story in a comment on Hacker News:
"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)"
Cherny also named approaches Anthropic plans to prototype, Apiiro notes in an update, citing Cherny's goal of "making sure auto mode catches this, building in basic secret scanning," and, when a reader noted the same can happen in auto mode when it asks about a sensitive command, answered "good catch."
Claude Code users had already filed a bug report on the issue on August 11, 2025, notes The Hacker News, but "An automated bot closed that report as 'not planned' on January 3, after 60 days without activity."
Three more bug reports were then filed, according to the researchers. "None got a reply from Anthropic, and three were closed automatically as inactive or duplicate."
You're too slow! Stole your secrets! (Score:2)
That was my main reaction to the story, which was actually interesting enough to keep me reading all the way to the end. I'm mostly focused on time these years, as in time >> money, but the details about how long this has been going on were pretty surprising.
Not surprised by the ineffectiveness of the slow humans in getting any attention to the matter. But that's also an ancient problem. All things support are classified as costs to be minimized. Most profit from ignoring complaints and hope they go a
What a bunch of blithering idiots (Score:2, Insightful)
Not the users, the makers of Claude. (The users just do not know any better and that is entirely expected.) Looks to me like the people at Anthropic have zero clue about IT security and they make pathetic beginner's mistakes. Are these really the people you want to trust with your secrets?
Re: (Score:1)
A big part is Anthropic (and every single other AI outfit), but a big part is also on the users who gave the AI access to everything.
The users should know better, and if they don't... what happens to the data they share is their fault (read the ToS and EULA).
AI sandbox (Score:2)
The decades long avoidance of sandboxing each application at the OS level is on the operating system companies.
I am surprised that any company or agency with financial, medical or other data would not run each application in its own isolated sandbox. Each application having its own binary folder, data folder, and limited access granted by the system administrator to network and shared disk folders.
Re: (Score:2)
Sandboxing at the OS level is an important security layer, but not one that resolves this issue.
Let's say that you are developing a backend application that writes to a database. If you make a change to the code, you might want to go ask the database if it's still writing correctly. Running a one liner to go check a row in the dev environment database is pretty mundane. Your code can run in the most puckered security constrained container, but the issue is where it reaches out.
There's a bunch of fixes here,
Re: (Score:3)
Re: (Score:2)
This isn't a centralized setting for all projects (which is available). You wouldn't want your Python app to be able to run Node.js commands.
So then going with personal project specific settings are stored in the project with a .gitignore entry is an extremely common pattern for example JetBrains [jetbrains.com] or local environment settings, like .env.local [nextjs.org] files. Sure, there's a few other patterns like Python venv or Ansible Vault. But there's a billion other examples of this pattern. Because hiding project specific sett
Re: (Score:2)
This isn't a centralized setting for all projects (which is available). You wouldn't want your Python app to be able to run Node.js commands.
Realistically, I don't care what language Claude runs commands in when working on a project. That doesn't have to match the language of the project. My preferences for what commands the tool is allowed to run have basically nothing to do with the project, with the exception of me expecting it to not access files outside a per-project sandbox, which should be just a list of directories that are part of the project.
Either way, the fact that a project can encompass multiple directories means that metadata ab
Re: (Score:1)
Maybe, just maybe... don't give AI your data, don't let it onto your device.
If it doesn't have access to all your data, it can't harm you... that's up to the user, though.
Re: (Score:1)
Once you sandbox every app (especially AI stuff) at the OS level... what does that leave you with? How much RAM or processer time?
Are you 1,000% sure that that (that you have) AI can _never_ escape it's sandbox?
If a single place isn't that sure, it doesn't count.
Re: (Score:2)
Re: (Score:2)
What happening is problem with people not understanding the tools fine grained permission system where the tool doesn't want access to everything. Literally it's in the Configure Permission documentation [claude.com]....
The data being "shared" isn't even being shared to Anthropic but the user publishing out to GitHub themselves. So the TOS/EULA have absolutely nothing to do with this. Anthropic could undoubtedly do better here, but it's not the comically evil scenario you are proposing.
You really should spend time read
Re: (Score:1)
Aww... you're giving me hints about reading stuff... *huggles himmy32*!
(BTW... it's a lower case 'o', not upper-case)
Any data that any AI outfit gets is stored and used to train the worthless thing... did you really expect Twitter or Facebook to _not_ store your data for _other_ usage? That's all covered in the ToS and EULA.
If I feed it a story I wrote, that story isn't mine anymore.
So... might be a good idea to not give it all your passwords and access to every bit of data about you.
Re: (Score:2)
No, the users too. If I had a nickel for every secret that's been checked into personal settings files in the repos I've admined, I wouldn't be paying for drinks that've needed for dealing with the fallout.
This is the same class as any other setting file, the big change here is that the volume of changes being made by agents is conditioning people to not check what's added in the commit.
Re: (Score:2)
Users do not and cannot understand the issue. They are not IT experts. Tools that make these mistakes too easy are 100% at fault. Blaming the user is just an attempt at shifting blame. Unless IT people finally start admitting that, things are not going to improve.
Re: (Score:2)
The crazy thing is Claude already stores a bunch of project-specific metadata in ~/.claude/projects... Such a bizarre move to store local project settings that aren't supposed to be shared in the project .claude folder which can contain other files that are meant to be checked in.
Re: What a bunch of blithering idiots (Score:2)
That's like saying companies should be able to produce an employee handbook that puts and end to major security mishaps. You can't control what an LLM does except by not giving it access to do anything. If you give it access to your filesystem and let it execute commands, there's is zero chance you will stop it from doing retarded shit.
These things don't think. They don't reason. They are random token generators. You people are hooking up random token generators to your IT infrastructure. You're a fucking m
Re: (Score:1)
Yes. But that means LLMs are not fit to be used by non-experts. (Which is something I am more and more think is the case, actually.) And the fault for giving non-experts access lies squarely with the LLM sellers and the C-levels in companies pushing their use.
These things don't think. They don't reason. They are random token generators. You people are hooking up random token generators to your IT infrastructure. You're a fucking moron. You deserve to get hacked. Your organization deserves to be laughed out of business.
Yes to all of that. Unfortunately the problem has gotten very large by now.
I find Claude quite helpful (Score:3)
But I don't give it direct access to anything. If I want it to review something, I paste it into the app. If Claude generates code, I review it... and I have to copy and paste it into the actual script / app / file. Not to mention it's pretty rare that Claude-generated code gets used as-is in anything I'm working on.
If something secret does manage to leak out, it'll be my own fault.
Re: (Score:2)
Re: (Score:2)
But I don't give it direct access to anything. If I want it to review something, I paste it into the app.
Last week I was using Claude Code and it needed information about the database I was coding against. It used my local AWS key to obtain the login account data and inspected the database without asking me. Another time it jumped out of the project root and made changes to another related project without asking me. It's simultaneously amazing and terrifying.
I've had to put a directive in all my .claude files telling it not to push branches to Gitlab automatically, or it will.
And that's why, boys and girls,... (Score:1)