A saved command approval can become a credential leak if it preserves a password or API key and later reaches a public repository. According to a November 7 report from The Hacker News, Claude Code can save an approved command verbatim in a project settings file when a developer selects its persistent approval option. The report headline cites 1,122 public copies on GitHub containing exposed passwords and keys.
This advisory is based on the available RSS headline and summary; the full source article could not be retrieved. The available material does not establish whether exposed credentials remain valid, whether attackers used them, or which software versions are affected. The practical priority is to inspect saved permissions and treat any published credential as compromised.
Why saved approvals deserve a security review
Developers often inspect application code for secrets while overlooking configuration created by their tools. A command containing an inline credential can leave another copy behind when software records that command for future permission decisions. If that configuration is committed and published, the credential may become readable outside the intended environment.
The reported issue concerns secrets embedded in saved commands. It does not establish that every Claude Code project leaks credentials, or that private repositories automatically become public. Exposure depends on what was recorded and where that file was shared.
What to check now
Review project settings and permission rules generated by coding assistants, especially in repositories where developers have approved commands containing authentication parameters. Look for inline passwords, API keys, authorization headers, database connection strings, and other sensitive values. Avoid copying suspected secrets into tickets or chat while investigating.
Check staged changes, existing tracked files, and repository history—not just the current working tree. A clean latest revision does not prove an earlier commit was safe. Use a reputable secret scanner as an additional control, but review its findings carefully: detection patterns can miss unfamiliar credential formats.
If a credential was published
Revoke or rotate the exposed credential promptly. Deleting the file is not sufficient because earlier commits, clones, or other copies may retain it. Identify the services and permissions attached to the credential, then review relevant access logs for unexpected activity during the potential exposure window.
Update legitimate applications to use the replacement credential and confirm the old one no longer works. Coordinate repository cleanup with collaborators; rewriting history can disrupt existing clones and cannot erase copies held elsewhere. If the scope is unclear, involve the service owner or security team rather than assuming the credential was harmless.
Reduce the chance of a repeat
Prefer a secret manager or an appropriate credential helper over pasting secrets directly into commands. Where environment variables are used, verify that the tool saves the variable reference rather than an expanded secret value. These approaches reduce risk but do not replace inspection.
Review persistent permission entries before committing project configuration. Keep genuinely local settings out of version control where appropriate, remembering that ignore rules do not remove files already tracked. Add secret scanning before commits and in continuous integration, and favor short-lived, narrowly scoped credentials.
The central lesson is straightforward: saved permissions are security-sensitive configuration, not disposable metadata. Include them in code review and incident-response checks.
Source: The Hacker News report