CADChain Blog
2026-11-07 13:20 News

Claude Code Secrets Leak: Apiiro Finds 2,539 Passwords and Keys in Public GitHub Repos via the Don't Ask Again File. What Engineering Teams Should Check Now | CADChain | CAD DRM & IP

On 5 November 2026, researchers at the application security company Apiiro published an analysis showing that a convenience button in Anthropic's Claude Code coding agent has left passwords and API keys in public GitHub repositories. When a developer approves a shell command with "Yes, and don't ask again", Claude Code saves that command word for word as an allow rule in a local settings file. If the command contained a password, so does the file. Across public GitHub, Apiiro counted 2,539 distinct secrets in 1,994 repositories.
Apiiro researchers Shmulik Cohen and Matan Giladi collected public GitHub data between 1 and 3 November 2026. They examined 104,185 public copies of the local settings file in 103,617 repositories and classified 1,122 of them, about 1.1%, as containing real secrets: 1,379 distinct values in total. When they added the shared project settings file, older versions in Git history and saved agent transcripts, the count rose to 2,539. The researchers say they notified affected organisations on 2 and 3 November, and one company confirmed that its exposed key was live.
This is not a story about one AI tool. Engineering teams now use coding agents to write CAD macros, PDM and PLM integrations, data migration scripts and connections to cloud storage, and those scripts often need a database password or a storage key. The finding shows how quickly a credential typed once into a terminal can become a permanent, public part of a repository, and how ordinary secret scanners can miss it.
TL;DR: an approval button turned into a credential store

Claude Code saves commands approved with "Yes, and don't ask again" as allow rules in .claude/settings.local.json, including any password or token written into the command. Apiiro found 1,379 distinct secrets in 1,122 public copies of that file, and 2,539 secrets across 1,994 public repositories once shared settings, Git history and transcripts were included. They include 379 database passwords, 122 Supabase service-role keys, 103 Supabase account tokens and 43 SSH credentials. Neither TruffleHog nor gitleaks flagged 215 of the 1,122 files. Lesson: rotate first, then clean up, and keep both credentials and design files out of reach of anything a repository can leak.

What did Apiiro find in Claude Code settings files?

Claude Code asks for permission before it runs a shell command. One of the answers is "Yes, and don't ask again". Anthropic's Claude Code settings documentation confirms that this choice saves the approval as an allow rule in .claude/settings.local.json, a per-project file meant for one developer's personal overrides. Apiiro's point is that the rule stores the literal command, so a password written into a database or SSH command ends up in a JSON file in the project folder.
Apiiro then searched public GitHub for copies of that file. Of the 104,185 copies it examined, 1,122 contained what the researchers classified as real secrets. In those files they found 1,379 distinct secret values. The wider count of 2,539 secrets across 1,994 repositories also covers the shared .claude/settings.json file that teams commit on purpose, versions that were deleted from the current file but remain in Git history, and agent transcripts that developers had saved into repositories. Press coverage says 63 organisations were implicated.
Apiiro did not test the credentials or contact the exposed hosts, so "real secret" means credible credential material, not a confirmed working key. Apiiro also sells security products. Even so, one notified company confirmed that its exposed key was live.

Which secrets were exposed?

The breakdown reported from Apiiro's data is dominated by credentials that open data stores directly: 379 database passwords, 122 Supabase service-role keys, 103 Supabase account tokens and 43 SSH credentials, including root logins passed through sshpass commands. A Supabase service-role key is designed for server-side use and bypasses the row-level security rules that normally limit what a user can read, so it gives broad access to the project's database and storage.
For an engineering company, the equivalent credentials are the ones that open the PDM vault database, the PLM server, the S3 or Azure bucket where exported STEP files and drawings sit, or the SSH account on the machine that runs nightly CAD batch jobs. Our guide to PLM integration with CAD DRM systems explains why these integration accounts usually hold far more access than any single engineer.

Why didn't the file stay out of Git?

Claude Code does try to keep the file private. According to the documentation, the first time it writes .claude/settings.local.json inside a Git repository that does not already ignore it, it adds the file to the developer's global Git excludes file, so it stays out of commits on that machine. If the developer created the file by hand, the documentation says to add it to .gitignore yourself.
The weakness is where that protection lives. A global exclude is a setting on one developer's computer. It does not travel with the repository the way a committed .gitignore entry does, so it does not protect a colleague's clone, a build agent or another tool that commits on the developer's behalf. Git's own rules add a second trap: ignore rules do not apply to files that are already tracked, so once the file is in a commit, later ignore entries do nothing. The documentation also notes that in the VS Code extension the approval card lets a developer choose the destination file, including the project's shared settings file, which is meant to be committed.
The problem is not new. iTWire reports that a Claude Code GitHub issue filed on 11 August 2025 described approved commands with API keys and tokens being stored in plaintext, and that the issue was closed automatically in January 2026 after inactivity, which is not evidence of a fix. Apiiro also traced Claude co-authored commits that changed the settings file in 539 of 1,105 repositories it followed up, while noting that this does not prove the agent introduced every credential.

Why did secret scanners miss so many?

Most secret scanners are good at recognising provider keys with a fixed prefix or format, such as cloud access keys. They are weaker at spotting a password that is just an argument in a command. Apiiro ran two widely used open-source scanners over the 1,122 secret-bearing files: TruffleHog flagged 643 (57.3%), gitleaks flagged 564 (50.3%), and neither flagged 215 (19.2%). Passwords set through PGPASSWORD=, passed with sshpass -p or typed after mysql -p often have no recognisable prefix at all.

What does this mean for CAD, PDM and PLM data?

Autodesk added a local MCP server to Inventor this month, Dassault Systèmes is putting AI assistants into SOLIDWORKS, and many teams already use general coding agents to write automation around their CAD and PLM systems. We looked at the wider shift in machine learning in CAD in 2026 and at one practical workflow in where a CAD AI agent fits between design brief and prototype. Every one of those integrations needs credentials, and every credential an agent touches can end up in a file, a log or a transcript.
Leaked credentials are one of the easiest ways into design data. Ransomware gangs that list manufacturers on leak sites increasingly show drawings and PDM exports as proof, as our analysis of 23 ransomware claims against Korean manufacturers showed. State-backed groups automate the same work: in our report on the ARTEX AI agent framework used in cyber espionage, attackers used AI agents against more than 200 organisations, including semiconductor and defence targets. And the code platforms themselves are targets, as the critical GitLab vulnerability CVE-2026-110264 showed for self-hosted design repositories.
There is also an IP angle. A trade secret is only protected if the owner took reasonable steps to keep it secret. Our explainer on the legal framework for trade secret protection of CAD designs sets out why courts look at access controls and records. A database password published in a public repository, left there for months, is hard to square with reasonable secrecy measures for whatever that database holds.
Where the secret ended upWhy it leaksWhat to do
Local agent settings (.claude/settings.local.json)Approved command saved word for word as an allow ruleRotate the secret, stop tracking the file, add it to the repository's own .gitignore
Shared agent settings (.claude/settings.json)Committed on purpose so the team shares permissionsReview every allow rule before committing; keep only patterns, never literal credentials
Git historyDeleting the file does not remove earlier commitsTreat the secret as burned; rotate, then plan history cleanup
Forks and clonesCopies outside your control keep the old fileRotation is the only fix that reaches every copy
Saved agent transcriptsFull conversations include the commands that were runKeep transcripts out of repositories; store them in access-controlled locations
Inline environment variablesA PGPASSWORD=... prefix still puts the password in the command textUse a secret manager or a runtime reference the agent never sees

What should engineering teams do now?

  1. Search your repositories today. Look for .claude/settings.local.json, .claude/settings.json and any saved agent transcripts in every repository, public and private, including history, not only the current branch.
  2. Rotate before you clean. Apiiro, iTWire and GitHub's own guidance agree: revoke or rotate any exposed credential first. Deleting the file does not remove earlier commits, forks or clones.
  3. Stop tracking personal settings. Run git rm --cached .claude/settings.local.json and add the file to the repository's own .gitignore, so the protection travels with the project instead of living on one laptop.
  4. Never put literal secrets in commands an agent runs. Use a secret manager or a runtime reference. An inline environment variable assignment still writes the password into the command text.
  5. Keep standing permissions narrow. Approve broad patterns only for harmless commands, review what the agent saved after each approval, and use separate low-privilege accounts for integrations.
  6. Scan for passwords in commands, not just key formats. Add pre-commit and CI checks that catch database and SSH passwords passed as arguments, since common scanners missed one file in five.
  7. Give integration accounts the least access possible. A PLM or PDM service account used by scripts should not be able to read every project. Our guide on how to audit CAD file access helps you see who and what actually opens design data.
  8. Protect the files themselves. Assume some credential will leak one day. When CAD files are encrypted at file level with their own permissions, a stolen storage key gives access to encrypted files, not to readable designs, and you can revoke access to CAD files after they are shared.
Keep design data safe even when a credential leaks. CADChain encrypts CAD files at file level, applies per-file and per-user permissions, logs every access and records ownership on a blockchain, so a leaked password does not automatically mean leaked designs.

👉 Protect your CAD files with CADChain

What does this say about AI agents and security?

Apiiro's finding fits a pattern we have followed for weeks. In October the EU AI Office sent its first AI Act requests for information over AI agents that broke into outside systems, covered in our article on AI Act enforcement and rogue AI agents, and a malicious pull request showed how AI supply chain attacks can reach CAD and PLM toolchains.
The answer is not to ban coding agents. It is to treat their configuration as security-relevant code: reviewed, scoped and kept out of public places, with secrets held somewhere the agent can use them without ever writing them down. The same principle applies to design data. A zero trust model for CAD file distribution assumes any single control can fail and keeps the files protected anyway.

How does this fit the bigger picture?

Our sister sites covered related risks this week.

Conclusion

Apiiro's research shows how a small usability shortcut can turn an AI coding agent into an accidental credential store: a command approved once was saved word for word, protected only by a setting on one laptop, and then published with the repository.
Engineering companies using agents for CAD, PDM and PLM automation should check their repositories now, rotate anything exposed, and make sure design files stay protected even on the day a password leaks.
Make a leaked password a contained incident, not an IP loss. CADChain protects each CAD file with encryption, granular permissions, revocation and a full access log, across CAD systems and suppliers.

👉 See how CADChain protects CAD files

FAQ: Claude Code secrets and engineering data

What did Apiiro find?

Apiiro researchers found that Claude Code's "Yes, and don't ask again" option saves approved shell commands word for word in .claude/settings.local.json. In 1,122 public copies of that file they found 1,379 distinct secrets, and 2,539 secrets across 1,994 public GitHub repositories once shared settings, Git history and transcripts were included. The research was published on 5 November 2026.

Is this a vulnerability in Claude Code?

It is a design behaviour rather than a classic exploit: the allow rule stores the literal command, including any credential in it. Claude Code adds the file to the developer's global Git excludes, but that protection stays on one machine and does not travel with the repository. No statement from Anthropic on the research was reported by 7 November 2026.

Were the leaked credentials used by attackers?

Not as far as is known. Apiiro did not test the credentials and no misuse has been reported. One notified company confirmed that its exposed key was live, so other secrets may also still work.

What should we do if our repository contains the file?

Rotate or revoke every credential in it first, then run git rm --cached .claude/settings.local.json, add the file to the repository's .gitignore, review Git history, forks, shared settings and transcripts, and replace literal secrets with references to a secret manager.

Does this affect CAD and PLM data?

It can. Engineering teams use coding agents to build PDM, PLM and cloud storage integrations, and the credentials for those systems can end up in the same files. A leaked database or storage credential can expose design data unless the files themselves are protected.

How does CADChain help?

CADChain encrypts CAD files at file level, applies per-file permissions, logs every access, lets you revoke access and records ownership on a blockchain. It does not scan repositories or replace secret management, but it limits what a leaked credential can expose.