Claude Code’s command approval feature can turn a developer’s one-time permission into a lasting credential leak. GitGuardian found 31,088 distinct secrets in public GitHub repositories’ .claude/settings.local.json files, with 5,343 still valid when detected. The concern isn’t simply that developers may put secrets in local files; it’s that a tool intended to remember a command approval can also preserve sensitive text embedded in that command.
The exposed data included database connection strings, cloud tokens, SSH passwords, Google API keys and Australian service credentials. GitGuardian researcher Guillaume Valadon also found secrets in public Docker Hub images, where configuration files can survive even when developers keep them out of Git. Taken together, the findings show how credentials can escape through two routine parts of software work: saving local preferences and packaging project files.
Approval rules can retain credentials
When Claude Code asks permission to run a shell command, developers can choose “Yes, and don’t ask again.” The tool saves an allow rule in the project’s .claude/settings.local.json file. That convenience reduces repeat prompts, but it also means the saved rule may preserve command details that were meant to be temporary.
A command that sends an API key in a curl request header, for example, may be recorded with the key intact. Claude Code adds the file to its local Git ignore settings, but that safeguard can fail across different machines or repository clones. A file already tracked by Git can also remain exposed, since ignore rules don’t remove content that’s already under version control. A local setting can become a shared artifact.
Of the detected occurrences whose validity GitGuardian could check, 67% contained working credentials. Database identifiers made up the largest group of valid secrets, with 2,280 distinct credentials, followed by cloud provider tokens and AI tokens. Those figures make the issue more than a theoretical concern: a substantial share of the checkable material could still grant access when researchers found it.
Typical secret scanners may miss some of these values. Passwords passed as command-line arguments or assigned through environment variables often lack the recognizable patterns that provider-specific detection rules rely on. That leaves teams with a gap between what a scanner is designed to recognize and what a developer’s workflow can store. If you're working in this space, the practical question is whether your checks inspect command history and assistant configuration as well as conventional secret files.
Docker builds can carry ignored files into images
GitGuardian found another 613 distinct secrets in Claude Code settings files across public Docker Hub images; 99 were valid when detected. They appeared across 543 image repositories and 7,625 tags. The counts describe both the number of affected credentials and how widely image artifacts can be copied or republished.
The exposure can happen when a Docker build copies an entire project directory into an image. Docker doesn’t automatically apply a repository’s .gitignore, so developers need a .dockerignore rule to keep local Claude Code settings out of the build context. The distinction is easy to miss: a file excluded from Git can still be available to a build, then travel inside the resulting image.
The scale of reuse can make a single credential difficult to contain. One valid Cloudflare API token appeared in 559 image tags. A database password was present in 643 tags across seven repositories. Those examples show why removing a file from its original source may not be enough; every copy of an image or tagged build can preserve the same credential.
And this is the part most people overlook: image tags can multiply the reach of a mistake without requiring a new leak each time. One build decision can leave a credential embedded in many published variants. The numbers here are underwhelming as evidence of how well routine safeguards are working.
Credential rotation matters after removal
Deleting a settings file from GitHub won’t retract credentials already distributed in published images. Developers should rotate exposed credentials, exclude sensitive configuration from both Git and Docker builds, and inspect existing images for secrets that may still be present. Removal addresses the visible copy; rotation addresses whether the credential remains usable.
GitGuardian recommends treating AI coding assistant settings as potential secret stores, scanning them alongside environment files and keeping credentials out of command strings by using environment variables. That approach reduces the chance that an approval record captures a secret directly, though teams still need to understand where environment values can be exposed in their own workflows. Better defaults help. Careful review still matters.
Valadon reported that monthly leaks in settings.local.json peaked at 12,535 occurrences in April 2026 and fell to 959 by October; GitGuardian said it didn’t know what caused the decline. The drop is striking, but without an explanation it doesn’t establish whether exposure fell because of changed behavior, better protections, or some other factor.
Claude Code lead Boris Cherny acknowledged the issue and said Anthropic was investigating safeguards, including built-in secret scanning and an auto mode. Those measures could reduce the chance of accidental retention, but the reported exposures also involve Git practices and Docker build configuration. Here’s the thing: a feature-level fix can’t by itself clean up credentials already copied into repositories and images.
For development teams, the immediate takeaway is practical: command approvals and container build rules both need to account for local configuration files that may contain live credentials. This is more significant than it looks because the leak path begins in routine convenience features, then crosses into systems that distribute code and images. A safer approval flow, explicit build exclusions, scanning, and prompt credential rotation all address different points in that chain. A saved permission should never be assumed harmless just because it’s local.
