Claude Code’s “Don’t Ask Again” Setting Is Leaving Passwords in Public GitHub Repos

AI coding tools are now part of everyday work. They run tests, install packages and talk to databases on your behalf. To do that, they often need your permission to run a command in the terminal. Claude Code, Anthropic’s coding assistant, asks before it runs most shell commands. That is a good default.

The problem starts with a convenient button: “Yes, and don’t ask again.” When you choose it, Claude Code can save the command so it will not bother you next time. Sometimes it saves a safe pattern, such as “run any npm test command.” Sometimes it saves the exact command you approved, word for word. If that command contained a database password, an API key or an SSH login, those secrets are now sitting in a plain text file in your project.

Security researchers who scanned public GitHub in early November 2026 found this file, .claude/settings.local.json, in 104,185 public copies across 103,617 repositories. Of those copies, 1,122 held at least one secret. Together they held 1,379 different secrets, across 63 organisations. This is not a break of GitHub itself. It is a habit plus a file that is far too easy to commit.

If your team uses Claude Code — or any AI assistant that can run commands — it is worth a one-hour check this week. At DayDecoder, a custom software company in Ahmedabad, we treat secrets in git the same way we treat a leaked .env file: rotate first, then clean up.

What “Don’t ask again” actually saves

Claude Code is a helper that can read your codebase, edit files and run terminal commands. By default, it asks you before it runs most of those commands. That prompt is there to stop the tool from doing something dangerous on its own.

If you approve a command and also say “don’t ask again,” the tool writes an allow rule into .claude/settings.local.json inside the project. The next time a similar command comes up, it can run without asking.

There are two kinds of rule. A pattern is relatively safe. For example, a rule that allows npm test with any arguments does not need to contain a secret. An exact command is the risky kind. If you once ran a command that included a live password, that full line can be saved. Researchers reproduced this behaviour with current models at the time of the research, including Opus 5.5 and Fable 5.1.

Here is a simple picture. You are late, and you need to check a staging database. You approve a command that includes the database password on the command line. You click “don’t ask again” so the assistant will not interrupt you every time. The password is now in a JSON file in your repo folder. If that file is ever committed, pushed, copied into a zip, baked into a Docker image, or published inside an npm package, the password goes with it.

Why the built-in protection is not enough

Claude Code does try to keep this file out of git. The first time it writes the file in a git repository, it can add the file to the user’s global git excludes. Git on that one computer then ignores the file in every repository.

That protection lives in one person’s git settings on one machine. It does not add the file to the project’s own .gitignore, so the rule does not travel when a colleague clones the repo, when the folder is turned into a repository later, or when someone copies the project to a laptop that does not have the same global excludes. It also does nothing for a file that was already committed.

Researchers also found that the tool itself sometimes commits the file. In 539 of the 1,105 repositories they could trace, a commit that listed Claude as a co-author changed the settings file. In those cases, a person may never have chosen “git add” on the file at all.

A member of the Claude Code team has said these settings files should not be checked into source control, and that the team was looking at ways to prevent this. Until the tool itself blocks the leak, the project still needs a repo-level ignore rule and a habit of keeping secrets out of commands.

What the November 2026 research found

The public scan looked at copies of the local settings file that anyone could read on GitHub. The headline numbers, from research published in early November 2026, are:

A value was counted as a secret when it matched a known key format, or when a password or token sat beside the address of a public server, and an automated review agreed. The researchers did not say whether any of those secrets still worked, except that one company they notified confirmed its key had been live.

At the time of that research, every file with a secret was still on its repository’s default branch. In half of those repositories, the file had been there for at least 217 days. That is a long window for anyone to have found and used a key.

Removing the file from the latest commit does not close the leak. Older versions of the file contained 734 more secrets across 509 repositories that no longer had those secrets in the current copy, usually because the file had been deleted. Forks spread the problem further: 211 forks of 74 repositories carried the same secrets as the originals.

A related shared file, .claude/settings.json, is often committed on purpose because teams want to share allow rules. Researchers found secrets in 298 of 76,011 public copies of that file, mostly inside allow rules. When they included the shared file, older versions, and saved agent chat logs, the total rose to 2,539 secrets across 1,994 repositories.

Of 16 coding agents whose documentation the researchers compared, Claude Code was the only one confirmed to save the full approved command in a project file by default. That does not mean other tools are risk-free. It means this particular habit is documented and already showing up at scale for Claude Code.

Why secret scanners missed so many of these files

Many teams already run tools such as gitleaks or TruffleHog in CI. Those tools are useful. They are not enough on their own for this leak.

Researchers ran both tools over every copy they found, without the tools’ extra “is this key still live?” step. Of the 1,122 files that contained a secret, gitleaks flagged 564 and TruffleHog flagged 643. Neither tool flagged 215 of them.

Most of the misses were passwords typed inside ordinary commands. Scanners are good at spotting a known key shape, such as an AWS access key. They are weaker when a password sits after something like PGPASSWORD=, sshpass -p or mysql -p, because that can look like a normal word in a normal command line.

If your CI “passed” last week, do not treat that as proof that this file is clean. Search for the file by name, including in git history, and read the allow rules yourself.

What to do this week

Do the steps in this order. The first step is the one people skip, and it is the one that actually shuts the door.

1. Search your GitHub organisation for .claude/settings.local.json and .claude/settings.json. Search the default branch and the git history, including repositories where the file was later deleted.
2. Rotate every password, token and key those files have ever held, before you tidy the repo. This includes database passwords, cloud keys, GitHub and npm tokens, SSH logins, and AI provider keys. A deleted file is still in history and in forks.
3. Check forks and backups. If a public fork still has the file, treat those secrets as public until they are rotated. Look at Docker images, zip archives, npm packages and shared folders too. The file is plain JSON, and it can travel outside GitHub.
4. Stop tracking the local file with git rm --cached .claude/settings.local.json, and add it to the repository’s own .gitignore. Do this in a shared template for every new repo, not only in one project.
5. Open the file on your own computer, even if it was never committed. Delete every allow rule that contains a secret.
6. Keep secrets out of commands. Load them from a secrets manager or from the environment, for example $DATABASE_URL or $AWS_SECRET_ACCESS_KEY. A saved rule should hold the variable name, not the secret.
7. Approve patterns, not one-off commands when you can, such as a rule that allows npm run with any script name. Never approve a command that has a live password in it.
8. Widen your secret scanning. Treat folders such as .claude/, .cursor/, .gemini/ and other agent memory directories as sensitive, the same way you already treat .env. Teach your scanner to look for passwords inside commands, not only for known key formats. Scan git history, not just the latest commit.

Safer habits for AI coding tools

The deeper lesson is not only about one button in one product. Coding agents now sit in the same place as a junior developer with access to your staging database. They see command lines, environment files and CI secrets. They also write files that you may not think to review.

A few habits reduce the risk a lot:

• Prefer short-lived credentials and role-based access over a long-lived personal key pasted into a command.
• Give an AI coding tool a separate, limited cloud account or database role for local work. Do not hand it the production owner password.
• Review the agent’s git diffs, including hidden folders, before you push.
• On shared machines and CI runners, do not store production secrets in project-level JSON files.
• If you use auto-approval modes, remember that a command can still be written to a settings file. Auto mode is not a substitute for keeping secrets out of the command line.

This advice also sits next to a broader problem we wrote about recently: stolen credentials being used to plant malware in GitHub pipelines. A password that leaked through a settings file can be used in the same way as a token stolen from CI. Rotation and least privilege help in both cases.

How we handle this at DayDecoder

DayDecoder is a custom software company in Ahmedabad. On the Laravel, Node.js and React codebases we build, we treat agent folders and .env files as secret-bearing by default. We add them to the project .gitignore, keep production credentials out of shell commands, and rotate anything that may have been committed.

If you want a second pair of eyes on a GitHub organisation, a Laravel or Node.js repo, or your secret-scanning setup, use the contact form. We reply within one business day.

FAQ

I already deleted the file from the repo. Am I safe?

Not until you rotate the secrets. The old file can still sit in git history, in forks, and in copies such as Docker images or zip archives. Delete the file after you have changed every key it ever held.

The file is only on my laptop. Do I still need to worry?

Yes, though the risk is different. A local copy can still be stolen by malware, synced to a shared folder, or committed later by mistake. Open the file, remove any rule that contains a secret, and add the file to the project .gitignore now.

Our secret scanner reported no problems. Can we skip the search?

No. In the early November 2026 research, neither of two popular scanners flagged 215 of the 1,122 secret-bearing files. Search for the file by name and read it.

Is this a vulnerability in GitHub?

No. GitHub is hosting public files that were committed to public repositories. The leak comes from a settings file that can contain secrets and is too easy to check in.

Does this also affect the shared .claude/settings.json file?

It can. That file is often committed on purpose. The same research found secrets in 298 of 76,011 public copies, mostly inside allow rules. Search for both file names.

What should I do first if I find a secret in the file?

Rotate that secret immediately. Then remove the file from git, add it to .gitignore, and check history, forks and any packaged copies of the project.