News · 2026-11-08

Claude Code permission rules can preserve secrets that later reach public repositories

Apiiro found credential-like values in 1,122 public Claude Code local settings files after studying how persistent command approvals store shell commands. A password embedded in an approved command can remain in a project file and become public if that file is later committed or otherwise shared; the researchers did not establish how many credentials were active.

Key facts

• Apiiro published its investigation on November 5, 2026.
• It identified 1,122 current files containing 1,379 distinct values under its classification rules, out of 104,185 public local settings files examined.
• Anthropic's documentation says persistent Bash approvals are stored as rules in .claude/settings.local.json.
• Apiiro's report describes the methodology; Anthropic's settings documentation explains the file and its Git exclusion.

A convenient button is at the center of the problem. A coding agent asks permission to run a command, and the user can approve it persistently so the tool does not keep asking. If the command itself includes a password or token, saving a rule based on that command can also preserve the secret as ordinary text. The approval does not itself publish the file. Publication needs an additional action such as tracking and pushing it, or sharing a copy through another channel.

Think of writing an office door code on a reusable permission slip. The slip is meant to stay in a desk drawer. The problem arises when the whole folder is copied into a public filing cabinet: the door code travels along with an apparently routine record of permission. The risk is in how the workflow stores and transports the command, not a finding that the language model independently leaked its training data.

Anthropic's permissions documentation describes the durable approval mechanism. Anthropic says Claude Code adds a global Git exclusion for the local settings file when it first writes the file inside a Git repository. That is a significant protection on the machine where it is configured. It is also distinct from a project-level ignore rule that travels with the repository, and Git ignore rules do not stop a file that is already tracked from being included in later commits. A normal clone does not copy an ignored, untracked file; the concern is a path that actually copies, tracks, or otherwise distributes the file.

Apiiro searched public code and commit indexes between November 1 and 3. Its 1,122 figure refers to current files, not people, organizations or confirmed breaches. The researchers classified 1,379 distinct values in those files using patterns and contextual checks, then filtered known false positives. They say they did not try the credentials or contact hosts. One company separately told them its key had been live; that single confirmation cannot establish the active share of the corpus.

A larger figure in the report covers additional sources and historical versions: 2,539 distinct classified values across 1,994 repositories. It must not be described as 2,539 secrets in the 1,122 current files. History also matters operationally: removing a secret from the latest file does not automatically remove copies from earlier commits or forks. Apiiro's comparison says two common scanners both missed 215 of the 1,122 classified files, including cases where ordinary-looking passwords appeared in command arguments. Those figures describe the researchers' classification and scanner test, not a measurement of valid credentials.

In the public discussion, Claude Code team member Boris Cherny said the team was “looking into what we can do to prevent this.” That is an investigation statement, not a shipped fix. The earlier issue report documents a plaintext-storage concern, but the exact affected and fixed versions remain unestablished. Apiiro's work was not independently replayed in the dossier.

The strongest counterargument is that a local permission rule is not a public leak and the researchers did not validate every credential. Both points are correct. The practical design question remains: a permission feature can preserve sensitive command text in a file within a project, while the default exclusion lives in a particular user's Git configuration. Keeping secrets out of literal commands, checking what Git already tracks, and rotating any credential that has actually been exposed address different parts of that chain. The related lesson on scoped credentials explains why limiting what a stolen credential can do matters even when storage protections fail.

Primary source, verified: read the paper →

Ground Truth. (2026, November 8). Claude Code permission rules can preserve secrets that later reach public repositories. Ground Truth. https://groundtruth.day/news/claude-code-permission-rules-can-preserve-secrets.html

@misc{groundtruth:claude-code-permission-rules-can-preserve-secrets,
  title  = {Claude Code permission rules can preserve secrets that later reach public repositories},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {nov},
  url    = {https://groundtruth.day/news/claude-code-permission-rules-can-preserve-secrets.html}
}

Topics: cybersecurity · ai-security · credentials · coding-agents