AI and security briefsSecurity

Is Claude Code leaking my secrets to GitHub, and how do I check?

By Brandon Da Costa, founder of Digiton Dynamics

Published 9 November 2026Updated 9 November 2026Editorial policy

Apiiro reported on 5 November 2026 that Claude Code's "Yes, and don't ask again" choice can save a full shell command, password included, in .claude/settings.local.json. It found real secrets in 1,122 of 104,185 public copies of that file. Search your repos and history, then rotate.

Who should act: Anyone who has approved Claude Code shell commands inside a git repository, above all on projects pushed to GitHub, and anyone who owns an organisation's repositories.

What happened

Apiiro researchers Shmulik Cohen and Matan Giladi published their findings on 5 November 2026 (iTWire, 7 November). Anthropic's documentation says that when you choose "Yes, and don't ask again" for a Bash command, Claude Code saves an allow rule in .claude/settings.local.json at the repository root. The rule holds the command text. A password typed inside that command is stored as plain text.

Apiiro checked 104,185 public copies of the file and classified 1,122, about 1.1%, as holding secrets, 1,379 distinct values in all. Counting git history, the shared settings file and agent transcripts, it reports 2,539 secrets across 1,994 repositories. Apiiro did not test the credentials. One notified company confirmed its key was live (iTWire).

Anthropic says the first time Claude Code writes the file in a git repository, it adds **/.claude/settings.local.json to your global git excludes file (Claude Code settings docs). That entry lives on one machine. It does not travel with the repository and it does not untrack a file already committed. iTWire says an August 2025 GitHub issue on the same behaviour was auto-closed in January 2026. I found no Anthropic statement on the research as of 9 November.

Who is affected

• Anyone who approved a command with a literal secret in it, such as a connection string, a token in a curl header or a key set inline, and chose "don't ask again".
• Repositories where the file was committed anyway: a fresh clone on a machine without the global exclude, a file added by hand or one tracked before the exclude existed.
• Anyone who can read a private repository holding the file. Apiiro counted public copies only.
• Teams that trust a clean scan. Apiiro, as summarised by Let's Data Science, says gitleaks flagged 564 of the 1,122 files and TruffleHog 643, with 215 caught by neither, because a password inside a command looks like an ordinary word.

What to do now

1. Find the files, then search the history of every branch.

   git ls-files | grep -E '(^|/)\.claude/settings(\.local)?\.json$'
   git log --all --oneline -- .claude/settings.local.json
   git log --all -p -i -G'(password|token|secret|apikey)' -- .claude/
   gh search code --owner YOURORG --filename settings.local.json

2. Scan files and history with both tools, since each misses some. Drop --only-verified for a wider net.

   gitleaks git --log-opts="--all" -v .
   gitleaks dir .claude
   trufflehog git file://. --only-verified
   trufflehog filesystem .claude

3. Rotate before you clean. Revoke each database password, Supabase service-role key, GitHub or npm token, AWS key and SSH login at the provider that issued it. Deleting the file does not remove history, forks or clones (iTWire).
4. Stop tracking the file and ignore it in the repository itself.

   git rm --cached .claude/settings.local.json
   echo '.claude/settings.local.json' >> .gitignore
   git check-ignore -v .claude/settings.local.json

5. Open each local settings file and delete any rule with a literal secret. Approve patterns, not whole commands, and read the password from an environment variable set outside the command. Writing it inline still puts it in the command text (iTWire).
6. Add deny rules and turn the sandbox on, as covered in Claude Code permissions and the Claude Code sandbox guide.

   {
     "permissions": { "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"] },
     "sandbox": { "enabled": true, "allowUnsandboxedCommands": false }
   }

Anthropic's docs say the sandbox is off by default and its denyRead does not stop the Read tool, so keep both. Wider context: is Claude Code safe.

What should have been in place

• .claude/settings.local.json in each repository's own .gitignore, because a global exclude covers one laptop.
• Secrets passed as environment variable references, never typed into an approved command.
• Pre-commit and CI scans that read agent folders such as .claude/ and include history.
• Deny rules for .env and secrets folders, plus the sandbox.

Questions people ask

Digiton's production review reads agent configuration files, secrets and git history together, and the checks it runs are on the Claude Code governance page.

How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.

Sources

1. iTWire, report on Apiiro's research with Anthropic's documented behaviour, 7 November 2026, read 9 November 2026. https://itwire.com/business-it-news/security/claude-code-approval-files-found-exposing-company-secrets-on-github-says-apirro-researchers
2. Claude Code docs on the settings files, read 9 November 2026. https://code.claude.com/docs/en/settings
3. Claude Code docs, configure permissions, read 9 November 2026. https://code.claude.com/docs/en/permissions
4. Claude Code docs, sandboxing, read 9 November 2026. https://code.claude.com/docs/en/sandboxing
5. Let's Data Science, summary of Apiiro's findings and scanner results, 7 November 2026, read 9 November 2026. https://letsdatascience.com/news/apiiro-finds-claude-code-approvals-leak-secrets-into-public-99d400fd

More briefs

How these briefs are sourced and corrected. All AI and security briefs