Claude Code team plans secret-leak checks after approval-file report

Claude Code’s Boris Cherny said on November 7 that the team would prototype checks for secrets retained in approval records. He cited auto-mode detection and basic secret scanning, responding to Apiiro’s report of credentials appearing in public repositories.

He gave no fix version or release date. Apiiro published its original findings on November 5 and added the response on November 8.

Apiiro reported finding values it classified as credentials in 1,122 of 104,185 public Claude Code local-settings files. Its explanation is that approving a command containing a password for future execution can preserve that command in a project file. Committing the file can then expose the embedded value alongside the code.

Apiiro examined public code and history without testing credentials or contacting hosts. The counts reflect its classification criteria, without establishing current validity or subsequent unauthorized use.

Where personal settings meet shared code

Claude Code’s settings documentation separates shared `.claude/settings.json` from personal `.claude/settings.local.json`. The files distribute team settings or apply personal overrides. The permissions documentation says approvals for repeated shell commands are retained per repository and command.

Claude Code adds a global exclusion when first writing the local file inside a Git repository if needed, its documentation says. This is separate from shared project exclusions. A manually created file needs an exclusion if Claude Code has not yet written to it.

Git’s own manual says ignore rules concern untracked files and do not affect files already tracked. Repository rules can be distributed to people cloning the project, while global rules apply in a user’s environment. A file’s intended role as local configuration and its actual tracking state are separate properties. The manual distinguishes exclusions shared with a project, repository-local working rules and a user’s cross-project preferences.

Cherny acknowledged that auto mode can encounter the issue too. The permissions documentation describes classifier review before actions run. It says permission rules are enforced by Claude Code, while prompt instructions shape what the model attempts. Changing a prompt does not change permitted access. Its approval table also distinguishes persistent shell-command approvals from file-edit approvals that last until the session ends. The same dialog can therefore create permissions with different lifetimes, depending on the tool.

GitHub also documents push protection, which examines supported secret types while code is being sent to a repository. A detection blocks the push and explains the problem before the data arrives. That is a different checkpoint from Claude Code’s review of whether a command may execute. Detection coverage and bypass options depend on the protection in use.

GitHub’s exposure guidance puts revoking or rotating an exposed password or token before deciding whether to clean repository history. That invalidates the old access value. Deleting a file in a later commit still leaves earlier commits and existing copies available, so removing its current appearance is only one part of handling a disclosure.

GitHub says rewriting history requires coordination: pushing from an old clone can reintroduce removed data, and separate forks need separate cleanup. Prototyping prevention, invalidating an exposed credential and cleaning distributed copies address different stages.