Notifications
Clear all
Topic starter
06/07/2026 9:37 am
TL;DR: A local permission file in Claude Code can ship credentials into published npm packages, according to Lakera, with 428 of roughly 46,500 monitored packages containing .claude/settings.local.json and 33 of those files holding secrets. The real issue is not the assistant itself but a packaging workflow that turns approved commands into a persistent exposure path.
NHIMG editorial — based on content published by Lakera: Your AI Coding Assistant Just Shipped Your API Keys
By the numbers:
Questions worth separating out
Q: How should security teams prevent AI assistant files from being published in packages?
A: Teams should treat AI assistant state files as release blockers until packaging rules explicitly exclude them.
Q: Why do AI coding assistants increase secrets exposure risk in software supply chains?
A: They increase risk because they persist command history that can include sensitive values, and release tooling often packages files without understanding their meaning.
Q: What breaks when local development files are included in release artifacts?
A: The boundary between private workstation context and public distribution disappears.
Practitioner guidance
- Exclude assistant state from every publish path Add .claude/ to npmignore, exclude it in build backend rules, and treat the file as non-release content in every packaging workflow.
- Inspect artifacts before upload Use dry-run and unpack checks to verify that tarballs, wheels, gems, and JARs do not contain local assistant settings files or other hidden secrets.
- Rotate any credential that may have shipped If a published artifact contained tokens, keys, or passwords, revoke and replace them immediately across every affected service and registry.
What's in the full article
Lakera's full research covers the operational detail this post intentionally leaves for the source:
- The scanner design used to monitor npm registry changes and inspect package tarballs for hidden .claude/settings.local.json files
- The exact credential types found in shipped files, including registry tokens, GitHub tokens, Telegram bot tokens, and plaintext login data
- Platform-by-platform packaging guidance for npm, PyPI, RubyGems, and Maven or Gradle source artifacts
- Concrete shell and archive checks practitioners can use to validate releases before publication
👉 Read Lakera's research on Claude Code files shipping API keys in npm packages →
Claude Code settings files in npm packages: what teams need to know?
Explore further
06/07/2026 9:52 am
.claude/settings.local.json is a secrets-bearing release artifact: The file is not just local state, it is a persistence layer for approved commands that may include tokens, passwords, and bearer headers. That makes it a non-human identity control surface, because the exposure comes from how machine-executed commands are stored and later redistributed. Practitioners should treat command-allowlist files as publishable secrets containers until proven otherwise.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why packaging hygiene and secret handling so often diverge.
A question worth separating out:
Q: What should teams do if a package may already contain leaked credentials?
A: Treat the credential as compromised from the moment the package was published, even if the issue is discovered later. Revoke the secret, replace it, and audit downstream artifacts, caches, and mirrors that may still hold the package version. Public tarballs are permanent enough that delayed discovery does not reduce exposure.
👉 Read our full editorial: Claude Code leaks API keys through published package files
