Apiiro researchers say remembered commands are carrying credentials into public repositories, exposing a gap between approving an agent’s work and controlling what it leaves behind.
You ask your AI coding assistant to check a database connection. It proposes a command, asks permission, and offers to stop interrupting you for that command in future. You approve it and get on with your work.
What you may not realise is that the approval itself can become another copy of your database password.
That is the problem examined in research published on 5 November by Apiiro’s Shmulik Cohen and Matan Giladi. They say Claude Code can retain a complete approved shell command, including credentials, in .claude/settings.local.json. If that file is committed and pushed to a public repository, the credentials go with it.
The researchers examined 104,185 public copies of that local settings file and classified 1,122, or about 1.1%, as containing secrets. Those files held 1,379 distinct values. Their broader investigation, including Git history, shared settings and agent transcripts, counted 2,539 distinct secrets across 1,994 repositories.
It’s important to note Apiiro did not try the credentials. Its classification identifies likely credentials from their format and context, and the research does not prove every one (or any one) still works. The findings establish an exposure risk – rather than an actual demonstrated breach.
What the approval remembers
Claude Code’s own documentation confirms that choosing “Yes, and don’t ask again” for a Bash command saves an allow rule in the project’s local settings file. This lets the tool run matching commands without repeatedly seeking approval.
The file is intended for personal settings, rather than something shared with everyone working on the project. Anthropic says the first time Claude Code writes it inside a Git repository, it adds an entry to the developer’s global Git excludes file if needed. That is a real protection, and it must be noted Claude is not simply publishing secrets by default.Advertisement
However, a global exclusion belongs to that developer’s machine. It does not travel with the project in the way a committed .gitignore file does. There is also a separate problem if the settings file has already been tracked: Git’s documentation explicitly says ignore rules do not affect files already under version control.
This distinction is pretty easy to miss. A filename containing “local” describes how the application uses it. It’s merely a label; it does not, by itself, prevent Git from tracking or publishing it.
At the same time, this is not an example of a hostile prompt persuading an AI model to steal a password. The reported failure occurs during an ordinary, authorised workflow. A credential used to do the work becomes part of the record that authorises the work next time.
Earlier reports describe the same problem
The underlying behaviour predates Apiiro’s latest count. A Claude Code issue opened in August 2025 reported that approved commands containing credentials were stored verbatim in the local permissions list. The report warned about accidental commits and credentials persisting in plaintext.Advertisement
That issue was automatically closed in January 2026 after inactivity. Its closure is not evidence of a fix; the visible discussion records an automated housekeeping action rather than a technical resolution.
Security firm ironPeak described its own experience in February 2026, finding that a committed Claude settings file contained approved commands with database passwords and API keys. It also published a tool to look for secrets in AI configuration files and their history.
Those reports support the mechanism described by Apiiro. They do not independently verify Apiiro’s new repository totals, and the figures should be read as the company’s findings. Apiiro sells application and agent security products.
The limits of the count
Apiiro collected public GitHub data between 1 and 3 November. Its method filtered common false positives, then used an LLM reviewer to assess masked candidates against a rubric. This additional check was part of Apiiro’s process, not independent replication of the study.Advertisement
The researchers say they notified affected organisations on 2 and 3 November, and one company confirmed its exposed key had been live. They also identified Claude-coauthored commits that changed the settings file in 539 of 1,105 repositories they traced. That does not establish that Claude introduced or pushed every exposed credential.
Nor does the publication establish whether the credentials remain usable today, whether anyone else accessed the systems, or whether a database password led to the theft of database contents. The public availability of a plausible credential is serious enough to investigate without adding those claims.
Check the files as well as the code
For development teams, the immediate task is to inspect the local settings file and its permission rules, along with any shared agent configuration and transcripts being committed. A review focused only on application source code can miss a credential sitting in a tool’s configuration.
If a secret has been exposed, GitHub recommends revoking or rotating it first. Deleting the current file does not remove earlier commits, forks or other people’s clones. History cleanup needs care and coordination, and should not delay disabling the credential.
Teams can then stop tracking personal settings and put the relevant exclusion in the repository’s own .gitignore. They should distinguish local overrides from deliberately shared settings, rather than assume every agent configuration file has the same purpose.
A secret manager or runtime variable reference can also keep a literal password out of an approval rule. The detail matters: putting the password itself in an inline environment-variable assignment still places it in the command text. Review what the agent actually saves, and keep standing permissions narrow.
The useful question when approving an agent’s command is therefore also what gets saved afterwards. The command may be perfectly reasonable to run, while the record of that permission is something you would never want published.Advertisement
Click Here For The Original Source
——————————————————–
