Claude Code Approval Setting Left Passwords in 1,122 Public GitHub Files, Apiiro Finds

When a developer approves a shell command in Claude Code and chooses "Yes, and don't ask again", the tool saves an allow rule to a file called .claude/settings.local.json inside the project. Apiiro's researchers, Shmulik Cohen and Matan Giladi, found that the rule can contain the full command as typed, so a database password or key embedded in that command is stored in plain text. If the file is committed and pushed to a public repository, anyone can read it.

The finding matters for any company letting engineers use AI coding agents, because it creates a copy of a credential in a place most secret-hygiene practices do not check. Security reviews tend to scan application code, not personal agent configuration files.

What the Scan Found

Apiiro examined 104,185 public copies of the local settings file and classified 1,122, about 1.1%, as containing at least one secret, with 1,379 distinct values among them. A broader search that also covered git history, shared project settings and agent transcripts turned up 2,539 distinct secrets across 1,994 repositories. The data was collected between November 1 and 3.

The researchers traced 1,105 repositories and found that 539 had commits co-authored by Claude that changed the settings file. That does not show Claude introduced or pushed every exposed credential, and Apiiro did not test whether the secrets worked. It said it notified affected organisations on November 2 and 3, and one confirmed that its exposed key was live, according to iTWire's account of the research.

The problem has surfaced before. Security firm ironPeak reported in February finding database passwords and API keys in a committed Claude settings file and released a scanning tool. A GitHub issue filed in August 2025 about plaintext credential storage was closed automatically in January 2026 for inactivity, which iTWire noted is not evidence of a fix.

Anthropic's Existing Safeguard

Claude Code's documentation says the "don't ask again" choice saves an allow rule to the project's local settings file. Anthropic says that when Claude Code first writes that file inside a git repository, it adds an entry to the developer's global git excludes list if needed. That protection lives on one developer's machine rather than travelling with the project in a committed .gitignore file, and it does not cover files git is already tracking. No direct response from Anthropic to Apiiro's research has been reported.

The researchers' advice starts with rotating any exposed credential, since deleting the file does not remove it from earlier commits, forks or clones. They recommend that teams stop tracking the local settings file and add it to each repository's own .gitignore, keep personal overrides separate from deliberately shared agent settings, and reference secrets through a secret manager or runtime variable rather than typing them into commands. An inline environment variable assignment still stores the password in the command text, Apiiro warned, so approvals should cover narrow command patterns rather than exact commands containing live values.

The research drew wide attention on Hacker News, where it gathered nearly 300 points and about 200 comments. Developers who have used the setting can check their own exposure by searching their repositories, including history, for the .claude directory.