Claude Code's Don't Ask Again reportedly leaked credentials into 1,122 public GitHub files

What happened

A Hacker News discussion this week carried a striking claim: Claude Code's Don't Ask Again option had exposed passwords in 1,122 public GitHub files. Two follow-up posts on dev.to picked the story up. One, an opinion piece, treats the number as evidence that convenience features can carry real security costs. The other, a technical walkthrough, deliberately declines to vouch for the exact figure and argues the issue is broader than any single tool: agent-generated configuration files have quietly become an unwatched store for secrets.

How credentials get captured

Coding agents typically ask permission before running shell commands. Choosing Don't Ask Again saves a rule so similar commands run unprompted next time; in Claude Code those local rules land in .claude/settings.local.json.

The exposure begins when the approved command itself contains a credential, for instance a health-check curl that authenticates with -u user:password. The stored permission rule then doubles as a plaintext copy of the password. Because the developer never typed the secret into a file by hand, the reflexes that guard .env files never engage, according to the dev.to walkthrough. If the settings file is not gitignored, an ordinary commit and push places the credential in a public repository's history. Even when the file never leaves the machine, the secret sits in plaintext on disk, exposed to backups, dotfiles repositories or a forced git add -f.

Not just Claude Code

The walkthrough stresses that the pattern is not specific to one tool. Anything that records command history or chat transcripts — it cites Aider's .aider.chat.history.md — inherits the same risk when developers paste secrets into prompts or commands. Developers learned to review .env; almost nobody reads a machine-generated JSON settings file before committing it.

Auditing your repositories

The post proposes a ten-minute check: run git ls-files filtered for the Claude settings file to see whether it is tracked; run git log --all against the same path to catch copies committed and later deleted; and scan full history with gitleaks in redacting mode, with TruffleHog as a second pass that can verify whether discovered tokens still work.

It adds a caveat: scanners reliably catch well-formed tokens such as GitHub's ghp_ keys or AWS AKIA identifiers, but often miss bespoke passwords embedded in curl arguments. For that gap the author outlines a small purpose-built scanner that flags permission rules containing basic-auth strings, URL-embedded credentials or password arguments, while printing nothing that would land a secret in terminal or CI logs.

If a secret has already leaked

Order matters. The most common mistake, the walkthrough argues, is rushing to delete the offending commits. Once a secret reaches a public repository it should be treated as stolen: forks, caches and automated GitHub scrapers may already hold copies, so rewriting history does not restore safety. The recommended sequence is to rotate the credential immediately, check the provider's audit logs for unexpected access, untrack the file and add it to .gitignore, and only then rewrite history with git filter-repo after warning the team — everyone must re-clone, or a stale push can reintroduce the secret. Repositories with many forks may need GitHub Support to purge remaining copies.

Layered prevention

The post stacks several defenses. Keep secrets in environment variables so a saved rule records only a variable name, and re-read any command containing a credential before approving it permanently. Maintain a global gitignore covering .claude/settings.local.json, local Claude markdown notes, Aider artifacts and .env. Add a custom gitleaks rule that targets agent settings files, run it as a pre-commit hook and again in CI with full history fetched, since hooks can be skipped. Enable GitHub's secret scanning and push protection where available. The shared .claude/settings.json is normally committed for the team, so review it like code rather than ignoring it. Finally, restrict what the agent can read, for example with a deny rule covering .env.

The companion dev.to opinion piece rounds this out with familiar hygiene: environment variables over hard-coded keys, code reviews that actively hunt for embedded credentials, and GitHub's encrypted secrets for workflows.

Why it matters

Agentic tools changed where secrets live. Credentials now flow into permission rules, settings files and chat logs that software writes, humans rarely open and repositories commit casually. The reported figure of 1,122 files may be imprecise — one of the posts says so explicitly — but the mechanism is not disputed: a feature built to stop repetitive prompts faithfully preserved the exact commands it was told to remember, passwords included. As agents gain broader standing permissions, the files that record those permissions deserve the same scrutiny, and the same tooling, as any other secret store.