Claude Code's “Don't Ask Again” Exposed Passwords in 1,122 Public GitHub Files

You have clicked “Don't Ask Again” a hundred times so the agent would stop interrupting you about every command. Convenient. But Apiiro researchers have shown that this convenience comes at a price: 1,122 files containing passwords were found on public GitHub, leaked specifically through these Claude Code permissions.

A caveat: we only have the headline and the Hacker News signal (114 points and 85 comments), not the full report. The mechanism below is therefore described as the most likely one, and the details should be checked against the original.

How a password ends up on GitHub

Imagine a typical session. You ask the agent to connect to a database and run a migration. It constructs a command in which the password appears directly in the connection string, for example as an argument or an environment variable. Claude Code asks for permission. You select “Don't Ask Again” so you do not have to approve it every time.

To remember your choice, the tool writes a permission rule to the project's settings file. If the rule is tied to a specific command, the entire command—including the secret—ends up in the file. From there, everything proceeds as usual: git add, commit, push. The settings file sits in the repository alongside the code, and if the repository is public, the password is available to everyone.

Importantly, nobody did anything obviously foolish. The user did not paste a password into the README or commit a .env file. The secret leaked as a side effect of a convenient feature that nobody sees as a place where data is stored.

Why this is more serious than an ordinary leak

Traditional secret scanners look for familiar patterns in source code and application configuration files. Agent settings files are often a blind spot: they are neither source files nor .env files, so the team's rules and expectations do not cover them.

There is a second layer to the problem. Agents readily insert credentials into the command line because that is the easiest way to complete a task. Any mechanism that remembers commands becomes a secret log. This is not limited to Claude Code: the same risks exist for any assistant that stores a list of permitted actions alongside a project.

The figure of 1,122 should also be interpreted soberly. That is what was found through public search. Private repositories, forks, and files that have already been deleted but remain cached are not included, which means the real scale is probably larger.

What to do right now

First, find the agent settings directory in your repositories and inspect the permitted commands. Treat anything resembling a password, token, or connection string as compromised: rotate the key first, then clean it up. Simply removing the line from the latest commit does not help because the git history remains.

Second, separate shared settings from local settings. Rules that the team wants to share should live separately from personal permissions, and the local file should be listed in .gitignore.

Third, add a secret scanner to pre-commit and CI, and explicitly include AI tool settings files in the scan. This is inexpensive insurance.

Fourth, do not give the agent secrets on the command line. Pass them through environment variables supplied by a secret manager or through short-lived temporary tokens. That way, even a remembered command contains nothing valuable.

The takeaway for product teams and founders

This is a good example of how convenient permission handling in agent tools creates a new attack surface. If you are building your own agent, consider exactly what you store when remembering a user's choice: a command template or its literal text, and whether it is written to a file that is included in git by default. Redacting secrets before writing and placing the file in a safe location take a couple of days of work; a leak across a thousand repositories costs far more.