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)
show comments
Aurornis
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.
show comments
tsergiu
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
show comments
lacoolj
This page is like 80% repeating itself
If you post output from AI, please remember to edit before publishing
show comments
tim-projects
Here is how to solve this:
Use a private dev repo and do all your dev inside it.
Releases go to a seperate public repo
In the private dev repo use a script which Cherry picks release files from a whitelist that you maintain in the public repo.
Essentially, you define the files and folder structure of a release and that ensures every release looks great with no cruft and it's never going to have .secret.json in or whatever
Hardcoded secrets is seperate and you can have another script to grep for those
binarymax
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.
show comments
ivan_gammel
This may not be a popular answer here, but it works as expected. Basic security hygiene means that you use password manager CLI, SSH agent, at worst temporary git-ignored env files, so that the secrets would never appear in the command line and you would never pass them to Claude.
And you git-ignore any local settings by default, to prevent accidental leaks. It is not hard thing to learn, many juniors I interviewed know this. Developers who like to shoot themselves in the legs should pay the price. People who hire careless workers and do not put them in compliant environment should pay the price too.
tomrod
More and more, I want a hard sandbox on these. For those of a similar security mindset, how are you sandboxing?
ohyes
This doesn’t seem like the right way to use secrets with an AI agent, in general.
I always have it write a script and then write the secret to a different file myself, then instruct the agent to use the secret file in the script. That way the secret never goes through an external entity.
I had thought this was common sense but now I’m realizing of course it isn’t, we have people with minimal experience using these tools and they don’t even consider that sending their bank password (or whatever) to a third party (even a relatively trustworthy one) is extremely risky.
tiku
Why does git even allow easy hidden file adding? It should be hard to add a .folder so noobs won't do that.
algonney
From my point the best way is to give the AI all the permissions every thing that he needs to not stop on the middle of his work and after he done from the project you should change all the secrets api's, database whatever and by that you will be on the safe side.
thierryzoller
Was reported as BUG on Dec 5, 2025 to Anthropic and automaticaly closed.
please dont forget basic operational security when using LLMs. they dont do everything for you. you can ask them to do all sorts of stuff, that doesnt mean you should.
secrets, encryption, publishing to public internet, scanning for vulnerabilities in your packages etc. etc. you need to take your own responsibility for and never rely on some bot automation or third party.
that includes if its important projects not relying on scanning tools but opening files yourself and verifying what's in there.
read things before you put them in a place where everyone can see them forever....
this is basic stuff. you guys did it beforen LLMs surely.
YOU are responsible. not Claude, not any external vendor, not any downloaded script. You as a person.
show comments
andirk
This is an issue because it is popular, not because it is novel.
Review your code before committing. Do code reviews on PRs.
show comments
zahlman
I feel like pointing out, there are quite a few sorts of projects that can be developed without requiring any secrets (at least until publishing time, and that's something you really don't need an LLM to do for you once the process is established).
theapiartist
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.
nunez
This is why you ALWAYS run gitleaks as a pre-commit hook, agent or not. It's saved me from myself so many times.
qezz
> 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
show comments
skeledrew
According to Claude docs, settings.local.json isn't to be committed. This is just people being the usual sloppy with secrets in repos, not something particular to Claude or AI in general.
The first extension I add to any coding agent is one that redacts or rejects any read/write of a secret or credential or credential file. It's annoying, and the agent can work around it, but better to add a weak guardrail than none at all. Best is to not give it access to any secrets, but that's not always possible.
This just in checking your secrets into source control exposes your secrets!
GaryBluto
People chose to upload a file containing their password and make it publicly accessible, I don't see a problem here.
teejaypeeps
The article reads as though an LLM wrote it
ry504
Relatable lol. Personal privacy and security goes out the window when you go full Claude
semiquaver
The solution, ironically, is always run in YOLO mode
cluckindan
The irony that the article is written with Claude…
show comments
mococa
Plain text secrets? Super rookie mistake!
system2
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.
show comments
globular-toast
Once again, devs shocked when random number generator has unpredictable results.
rvz
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.
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)
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'm super paranoid about the level of access AI agents have. At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them.
The best solution I've been able to come up is using an ephemeral vm (on an isolated network) per task, using --dangerously-skip-permissions so it doesn't bother me. I couple that with an API proxy that lets me restrict the permissions it has to external services. So e.g. where a quickbooks API key gives the holder "god mode" access, the proxy lets the agent do certain read commands without confirmation, but all write endpoints except uploading receipts require confirmation on my phone before they'll be allowed to hit the quickbooks servers. I no longer need to trust that the agent will interpret my readonly wishes correctly.
Tooting my own horn here, but this setup works incredibly well! I've been able to connect dozens of services safely where I absolutely do not trust giving raw, overpowered credentials or oauth integration to the agent directly. I actually just released the API proxy today at https://keycontain.com
This page is like 80% repeating itself
If you post output from AI, please remember to edit before publishing
Here is how to solve this:
Use a private dev repo and do all your dev inside it.
Releases go to a seperate public repo
In the private dev repo use a script which Cherry picks release files from a whitelist that you maintain in the public repo.
Essentially, you define the files and folder structure of a release and that ensures every release looks great with no cruft and it's never going to have .secret.json in or whatever
Hardcoded secrets is seperate and you can have another script to grep for those
I keep all my creds in a password manager (1Password in my case) and Claude can’t see them - when a cred is needed it runs a script that calls the op CLI and I tap my fingerprint for access. Sometimes I need to do it a bunch of times for complex operations, but it’s worth it.
This may not be a popular answer here, but it works as expected. Basic security hygiene means that you use password manager CLI, SSH agent, at worst temporary git-ignored env files, so that the secrets would never appear in the command line and you would never pass them to Claude. And you git-ignore any local settings by default, to prevent accidental leaks. It is not hard thing to learn, many juniors I interviewed know this. Developers who like to shoot themselves in the legs should pay the price. People who hire careless workers and do not put them in compliant environment should pay the price too.
More and more, I want a hard sandbox on these. For those of a similar security mindset, how are you sandboxing?
This doesn’t seem like the right way to use secrets with an AI agent, in general.
I always have it write a script and then write the secret to a different file myself, then instruct the agent to use the secret file in the script. That way the secret never goes through an external entity.
I had thought this was common sense but now I’m realizing of course it isn’t, we have people with minimal experience using these tools and they don’t even consider that sending their bank password (or whatever) to a third party (even a relatively trustworthy one) is extremely risky.
Why does git even allow easy hidden file adding? It should be hard to add a .folder so noobs won't do that.
From my point the best way is to give the AI all the permissions every thing that he needs to not stop on the middle of his work and after he done from the project you should change all the secrets api's, database whatever and by that you will be on the safe side.
Was reported as BUG on Dec 5, 2025 to Anthropic and automaticaly closed.
https://github.com/anthropics/claude-code/issues/13106
please dont forget basic operational security when using LLMs. they dont do everything for you. you can ask them to do all sorts of stuff, that doesnt mean you should.
secrets, encryption, publishing to public internet, scanning for vulnerabilities in your packages etc. etc. you need to take your own responsibility for and never rely on some bot automation or third party.
that includes if its important projects not relying on scanning tools but opening files yourself and verifying what's in there.
read things before you put them in a place where everyone can see them forever....
this is basic stuff. you guys did it beforen LLMs surely.
YOU are responsible. not Claude, not any external vendor, not any downloaded script. You as a person.
This is an issue because it is popular, not because it is novel.
Review your code before committing. Do code reviews on PRs.
I feel like pointing out, there are quite a few sorts of projects that can be developed without requiring any secrets (at least until publishing time, and that's something you really don't need an LLM to do for you once the process is established).
This 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.
This is why you ALWAYS run gitleaks as a pre-commit hook, agent or not. It's saved me from myself so many times.
Or am I missing something
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.
here's what they look like btw https://github.com/Marius0G/iDrip/blob/2d79c54fb22025aaa8cf6...
I mean it'd be crazy if this worked:
https://github.com/search?q=path%3A**%2F.claude%2F*.json+CLI...
oh look..
The first extension I add to any coding agent is one that redacts or rejects any read/write of a secret or credential or credential file. It's annoying, and the agent can work around it, but better to add a weak guardrail than none at all. Best is to not give it access to any secrets, but that's not always possible.
Here's a few for Pi: https://pi.dev/packages/@k3_2o/pi-secrets https://pi.dev/packages/@spences10/pi-redact https://pi.dev/packages/keyshroud
A couple for OpenCode: https://github.com/boxpositron/envsitter-guard https://github.com/kenryu42/cc-safety-net https://github.com/inkdust2021/opencode-vibeguard
This is also an example of how someone's personal settings don't belong in a source code repo at all.
I find it pretty annoying when someone commits their harness specific files into a repo - put that stuff under $HOME/.claude/
If you really need to commit private files to GitHub, use Turbocrypt https://github.com/jedisct1/turbocrypt/blob/main/docs/git.md
"git add . " considered harmful
This just in checking your secrets into source control exposes your secrets!
People chose to upload a file containing their password and make it publicly accessible, I don't see a problem here.
The article reads as though an LLM wrote it
Relatable lol. Personal privacy and security goes out the window when you go full Claude
The solution, ironically, is always run in YOLO mode
The irony that the article is written with Claude…
Plain text secrets? Super rookie mistake!
I still don't understand why people are using GitHub for their vibecoded projects. Just install git locally on your own NAS and control it there. What a weird fetish to publish online.
Once again, devs shocked when random number generator has unpredictable results.
Vibe coders in open source proudly don't read the (slop)code and place all their agents in autonomous loops without them knowing that Claude leaked their passwords and environment variables on GitHub.
This incident would have been caught in an open source harness. This one is closed source malware, and you don't know what Claude Code does internally to behave like this.
Yet another reason why you cannot trust a closed harness.