Claude Code documents permanent Bash approvals stored in .claude/settings.local.json; Apiiro found secrets in 1,122 public copies of that file, The Hacker News reported on November 7, 2026. The immediate defensive priority is to rotate exposed credentials before removing tracked files, because earlier versions can remain in repository history and forks.

The permissions documentation and settings documentation establish the approval mechanism, not Apiiro's scan counts. The findings describe exposure, not a confirmed breach of Anthropic or proof that anyone used the credentials.

#How can a standing approval retain a secret?

Claude Code's settings docs say choosing “Yes, and don’t ask again” for a Bash command saves an allow rule in .claude/settings.local.json. The permissions docs describe that approval as permanent per repository and command. They also document permanent approvals for WebFetch domains; this is not a claim that every tool approval behaves identically.

According to the permissions docs, the rule applies to future sessions anywhere in the repository, including subdirectories and worktrees.

The Hacker News reports that saved rules can be patterns or exact commands. When a rule stores an exact command, a password or token typed into it is saved in plain text too. A pattern is not automatically a secret, and not every standing approval contains one.

#What did Apiiro find, according to The Hacker News?

Apiiro's scan covered 104,185 public copies of the local-settings file across 103,617 repositories, The Hacker News reported on November 7. According to that report, Apiiro classified 1,122 copies, about 1.1%, as holding at least one secret, with 1,379 distinct secrets in those copies.

The Hacker News says Apiiro counted a value when it matched a known key format, or when a password or token appeared beside a public server's address, and an AI reviewer agreed. This is classification, not a test that a credential remains valid.

Apiiro's broader total was 2,539 secrets across 1,994 repositories, as reported by The Hacker News. That total includes shared .claude/settings.json files, older versions and saved agent chat logs. It is not the count for current local-settings copies alone. The same report attributes to Apiiro secrets in 298 of 76,011 copies of the shared settings file, mostly inside allow rules.

#Why is the existing ignore protection not enough?

The settings docs say that the first time Claude Code writes the local file in a repository that does not already ignore it, it adds **/.claude/settings.local.json to the user's global git excludes. It does not add that entry to the project's .gitignore.

The Hacker News reports the researchers' warning that this protection stays in one user's git settings on one computer, does not travel with the project and does nothing for a file already committed. Removing a tracked file also does not undo disclosure in older versions or forks.

#What should developers check in their own repositories?

The Hacker News's remediation guidance puts credential rotation before file cleanup. For developers reviewing only their own repositories and history, the priorities are:

  • Check for both settings files, including repository history where the files have been removed.
  • Rotate every password, token and key the files have ever exposed before cleaning up.
  • Stop tracking the local file and add it to the project's .gitignore.
  • Review the local copy on the developer's own computer, even if never committed, and delete rules containing secrets.
  • Keep secrets out of literal commands. Refer to variables supplied by a secrets manager so a saved rule holds a variable name rather than a secret.
  • Prefer approval patterns over exact commands, without assuming a pattern makes every approval safe.

The Hacker News also reports the researchers' warning that uncommitted copies can travel in packages, container images, archives or synced folders. A repository-only review is therefore not the whole local-file check.

#How is this different from other coding-tool security incidents?

This finding concerns accidental settings-file commits, not a malicious extension. Our separate report on the Claude Code marketplace extension and SSH backdoor covers that different issue. For other coding-tool credential coverage, see the OpenCode console and provider API keys; it is not evidence of misuse in this finding.

Our analysis: A standing permission rule and a credential are different things, but an exact saved command can combine them in one file. The practical distinction is between preventing a future commit and recovering from an existing disclosure. A local ignore rule addresses the former; rotating exposed credentials must come before treating file removal as cleanup.

#What is still unclear?

The Hacker News says Apiiro did not test whether the discovered secrets still worked, and the researchers do not say whether anyone used them. Neither statement establishes that misuse did or did not happen.

The opened documentation does not establish an Anthropic response or a specific shipped fix for this exposure finding. No newer-version fix or documentation-change release date is asserted here.