Your AI coding assistant is quietly shipping your secrets

AI coding agents are starting to leave a new kind of paper trail in your codebase: configuration files, logs, and helper artifacts that were never meant to leave your laptop. In this post I walk through how I stumbled on one such trace, how others expanded the research, and why this feels like an ecosystem issue rather than a single bug.

One .claude folder in an npm package

This started the boring way: with a small bug-bounty-style secret scanner I run over published artifacts.

While looking at npm packages, I noticed something that should not have been there at all: a .claude/settings.local.json file shipped inside a published tarball, complete with real secrets. The contents made it obvious this was not just a harmless cache: inline curl commands with Authorization: Bearer … headers, API_KEY=… environment variables prepended to commands, and other traces of day-to-day development with an AI coding assistant.

Claude Code's own documentation describes .claude/settings.local.json as a project-level file for personal overrides, stored under the .claude/ folder at the root of your project and intended to stay local rather than be shared with the rest of the team. It is exactly the kind of file you never want in an npm tarball.

I posted a short note on LinkedIn calling this out, showing that .claude/settings.local.json was already shipping to npm with real tokens inside.

Lakera's research on package ecosystems

The Lakera research team picked up that LinkedIn post and decided to see how widespread the problem really was. They built a registry-side scanner that tailed the npm CouchDB changes feed, downloaded new and updated package tarballs, and extracted .claude/settings.local.json when present for analysis.

Across roughly 46,500 packages observed in the scan window, 428 contained a .claude/settings.local.json file, and 33 files across 30 packages held actual credentials. That is about one in thirteen settings files turning out to be sensitive.

The exposed data in those files was exactly what you would expect when developers hit "allow always" on commands during active Claude sessions: npm authentication tokens, GitHub personal access tokens, Telegram bot tokens, Hugging Face tokens, production bearer tokens, and plaintext test credentials used in provisioning scripts.

In the same write-up, Lakera also shows that this is not just an npm problem. They demonstrate similar issues across other ecosystems, with AI-agent traces ending up in Python, Java, and container artifacts as well.

Lakera's blog post "Your AI Coding Assistant Just Shipped Your API Keys" is the canonical reference here, and the numbers above come from their research.

Measuring the web with webcensus

npm is just one way these traces escape. As Lakera shows, the same pattern appears when AI agents are used across multiple language ecosystems and build pipelines.

To understand how often .claude/settings.local.json makes it all the way into deployed web assets, I built a simple scanner called webcensus and ran it across several large domain lists.

Across different lists, the result was consistently around 1 out of every 1,000 websites exposing .claude/settings.local.json over HTTP.

In many cases, the file contained the same kinds of artifacts as in the package studies: live API tokens and database credentials baked into previously approved commands, plus hard-coded backup paths, internal hostnames, and other "security by obscurity" details that can make lateral movement easier once you are in.

So we now had two separate but related data points: secrets hiding in .claude/settings.local.json inside package registries, and the same file occasionally making it into production web roots.

And .claude/settings.local.json is just one very visible example. The same class of problem exists for other AI agents and their own folders and files — from local state and logs to agent-specific config and instruction documents.

GitHub "dorks" for AI-agent traces

If a file can end up in tarballs and web roots, it can also end up in GitHub.

At that point it started to feel a lot like the Google-dork days again: trivial search queries returning obviously sensitive data. If you were doing security in the 2000s, this will feel familiar — simple queries, surprisingly naive issues everywhere.

A few examples that consistently surface real tokens inside .claude/settings.local.json:

And it is not just Claude. OpenAI's Codex CLI keeps authentication state in ~/.codex/auth.json, and the official documentation explicitly tells you to treat this file like a password because it holds API keys and access tokens in plain text. Seeing path:/.codex/auth.json return live API material on GitHub makes it clear that people are committing it anyway, often as part of rushed, AI-assisted workflows.

All of these are just different lenses on the same underlying issue: long-lived allowlists and auth caches, quietly accumulating secrets, then being swept up by whatever your default packaging or bundling workflow happens to be.

Apple's CLAUDE.md moment

This problem is not limited to settings files either. Sometimes the "AI exhaust" is more subtle — internal prompts, instructions, and architecture notes.

On May 1st 2026, security researcher Aaron (@aaronp613) noticed that Apple had accidentally shipped CLAUDE.md files inside the Apple Support app update (v5.13). Reporting later pointed out that these appeared to be internal Claude-related instruction documents, and that they referenced internal systems such as Apple's "Juno AI" and other support tooling.

Not long after Aaron's tweet started making the rounds, Apple released an emergency hotfix (v5.13.1) whose only visible purpose was to remove those Claude-related files from the bundle, which strongly suggests they were never meant to ship in the first place.

You can see examples of that coverage here: News9Live and Hacker News.

Even an organization with Apple's release discipline still managed to leak AI-agent traces into a production app, and then had to scramble to pull them back once someone noticed.

Why this feels like an ecosystem bug

So far I have reported most of the clearly critical cases I encountered — the ones with active cloud tokens, production database credentials, or obviously exploitable configuration details. But at this point it no longer feels like a queue of individual bugs to close; it feels like an ecosystem-level footgun.

A few patterns stand out:

• Defaults lag behind reality. Many .gitignore, .npmignore, and packaging templates were created before AI agents started generating local state in project roots, so they do not know about .claude/, CLAUDE.md, .codex/auth.json, or equivalent files from other tools.
• Tooling assumptions leak. Claude Code's settings model makes sense for a human ("personal local file in your project") but interacts badly with build tools that blindly package "whatever is in the tree." Codex's choice of a single plaintext auth.json makes sense for CLI convenience, but becomes dangerous when developers treat it like just another dotfile that can be copied around.
• The long tail is unmanageable. Between npm, PyPI, RubyGems, container registries, static hosting, CI artifacts, and mobile app bundles, there are simply too many places these traces can land, and it is increasingly visible that AI-assisted development is introducing new, very basic leakage paths.

We are also seeing more independent reports and articles describing the same pattern: AI-assistant traces quietly making their way into public artifacts, and only being noticed once someone happens to look in the right place.

What we can realistically do

We are not going to manually clean the internet of .claude/settings.local.json, CLAUDE.md, and auth.json files. The best we can do is push the ecosystem in a safer direction and raise awareness.

• Treat AI-agent local files like .env. Don't ignore the entire .claude/ folder — teams legitimately use .claude/settings.json, .claude/agents/, and CLAUDE.md for shared rules and skills. Instead, make sure clearly per-developer files like .claude/settings.local.json stay out of source control and build outputs, and be careful when you mirror files like ~/.codex/auth.json into project directories for CI.
• Audit what you actually ship. Use npm pack --dry-run, twine check plus manual inspection, jar tf, or your platform's equivalent to list artifact contents before publishing, and explicitly look for AI-agent paths.
• Scan artifacts, not just repos. Secret scanners and SAST should run on the final bundle, tarball, container image, or app package where these files actually show up — not only on the source tree.
• Harden agent defaults. AI tools should be opinionated about not storing inline secrets in plain text, and about never writing those files into locations that standard packaging flows sweep up by default.

I will keep poking at the problem and reporting the worst offenders, but this is not something one person (or one company) can "fix" alone. At this point the most practical thing we can do is keep talking about it — so that shipping your AI assistant's exhaust to production becomes as obviously wrong as checking in .env ever was.