Skip to content
  • Home
  • News
  • Claude Code Secrets on GitHub

Claude Code “Don’t Ask Again” Approvals Exposed 2,539 Secrets on GitHub

Laura Bede

By Laura Bede . 8 November 2026

Journalist

Miklos Zoltan

Fact-Checked this

When you tell Claude Code “Yes, and don’t ask again,” it saves the approved command word for word, password included. Researchers found more than a thousand of those files on public GitHub with secrets inside.

Security firm Apiiro searched GitHub from November 1 to 3, 2026, and found 1,122 public copies of Claude Code’s local settings file holding at least one secret. Counting older commits, forks and the shared project settings file, it found 2,539 secrets in 1,994 repositories.

Apiiro did not test whether the credentials still work. It contacted affected organizations, and one confirmed that its exposed key had been live.

A Click That Writes the Password Down

Claude Code asks before it runs a shell command on your computer. Pick “Yes, and don’t ask again,” and it saves an allow rule in .claude/settings.local.json inside the project, Anthropic’s documentation says. The rule is the command itself. A database password typed into a login command, an SSH password or an API token in a request header all land in that file as plain text.

Of the 104,185 public copies Apiiro checked, about 1% held a secret, 1,379 distinct ones in all. Database passwords led with 379. Apiiro also counted 122 Supabase service-role keys, 43 SSH logins (some with root passwords), 42 GitHub, GitLab and npm tokens, and 23 AWS keys.

Deleting the file later doesn’t make the secret go away. Older commits held 734 more secrets in 509 repositories, and 211 forks of 74 repositories carry the same secrets as the originals. The shared .claude/settings.json, which teams commit on purpose, had secrets in 298 of 76,011 copies. Apiiro also found secrets in saved agent conversations, memory files and deployment notes.

Most of the 63 organizations it identified are software companies.

Why the Built-in Safeguard Misses Them

Anthropic does try to keep the file private. The first time Claude Code writes it inside a git repository, it adds **/.claude/settings.local.json to your global git excludes file, so git ignores the file in every repository on that computer.

That protection sits in your own git settings, not in the project, and several common cases fall outside it:

  • The folder became a repository later. If it wasn’t a git repository when Claude Code first wrote the file, no exclude was added.
  • You created the file by hand. Anthropic’s docs say you then have to add it to .gitignore yourself.
  • Git already tracks it. Ignore rules don’t apply to files git already tracks, git’s documentation says. A file committed once goes out again with every change.
  • The package isn’t built by git. npm picks the files for a package from the package’s own .npmignore or .gitignore files (npm docs), not from your global git settings.

Packages have already leaked this way. AI security company Lakera scanned about 46,500 npm packages and found the settings file in 428 of them. In 30 packages it contained credentials, among them npm publish tokens and GitHub access tokens. Lakera notes that published npm tarballs are permanent.

Nor is the problem new. A bug report on Claude Code’s GitHub tracker described plain-text credentials in approved commands in August 2025, Cyber Security News notes.

Secret Scanners Catch About Half

Running a scanner over your repositories won’t settle it. Of the 1,122 files, Gitleaks flagged 564 and TruffleHog 643, and 215 slipped past both. Scanners are good at tokens with a known shape, such as AWS keys or GitHub tokens. A password typed after -p in a database command looks like any other word, which is why Apiiro advises searching for passwords inside commands, not only for recognizable keys.

A plain-text file on a laptop is also within reach of malware. The Shai-Hulud worm that hit npm in 2025 ran TruffleHog on infected developer machines to collect credentials.

What to Do If You Use Claude Code

  1. Read your rules. Open .claude/settings.local.json and .claude/settings.json in each project and go through the allow list. Look for passwords, tokens, connection strings like postgres://user:password@host and Authorization headers.
  2. Check whether git ever had the file. git log --all --oneline -- .claude/settings.local.json lists every commit that touched it; no output means it was never committed in that repository. On GitHub, a code search for path:.claude/settings.local.json with user: or org: and your name shows what’s public.
  3. Rotate first. Change the password or revoke the key before you delete anything. Clones and forks keep their copies, so removing the file doesn’t take the secret back.
  4. Then clean up. git rm --cached .claude/settings.local.json stops git tracking it. Add the path to the project’s .gitignore too, so the rule protects everyone who clones the repository, not just your computer. If you publish to npm, add .claude/ to .npmignore if you have one (or list what to ship in the files field of package.json) and run npm pack to see what goes out.
  5. Keep secrets out of commands. Put them in environment variables or a secret manager, so the command, and the rule Claude Code saves, reads $DB_PASSWORD instead of the password. If an approved rule already holds one, edit it down to a pattern; Anthropic’s docs show rules like Bash(npm run test *).

Our Mission

We believe security online security matters and its our mission to make it a safer place.