Feature Request: Built-in credential detection for file writes and routines
Problem
When Claude Code generates routine instruction files or scripts that require authentication, the agent embeds live credentials (API keys, tokens, passwords) directly into the file content. These files are then committed to git and pushed to remote repositories, exposing credentials in version control history.
This happens because:
- There is no credential pattern detection on file writes (e.g., scanning for
ghp_,AKIA,sk-,Bearerpatterns) - There is no standard placeholder syntax documented for routines (like
${{ secrets.TOKEN }}in GitHub Actions) - There is no runtime secret injection mechanism for routines
- The agent has no explicit guidance to avoid hardcoding credentials in files that will be committed
Real-World Example
During normal use, I asked Claude Code to set up a routine requiring GitHub authentication. The agent:
- Embedded my live GitHub PAT directly in a
git cloneURL inside an instruction file - The file was committed across 30 commits
- The credentials remained in git history for ~39 hours before I noticed
I was running in bypassPermissions mode. Pre-tool-use hooks exist as an opt-in mechanism, but they are not surfaced to users during bypass mode setup, not configured by default, and require users to know they exist and write their own secret-detection logic.
Proposed Solution
Minimum Viable
- Add a built-in credential pattern scanner that runs before file writes
- Warn the user when a known credential pattern (e.g.,
ghp_[A-Za-z0-9]{36}) is detected in file content being written - This should work regardless of permission mode
Ideal
- Document a standard placeholder syntax for credential references in routines (e.g.,
${GH_TOKEN}) - Add agent-level guidance to prefer environment variables over hardcoding
- Surface pre-tool-use hooks during bypass/auto-accept mode setup with a suggested secret-detection hook
- Consider a built-in
--detect-secretsflag or default hook
Why This Matters
- Users in bypass mode trust the agent to operate efficiently, not to make unsafe security decisions
- Credential exposure in git history is permanent unless the history is rewritten
- GitHub bots actively scan for credential patterns — exposure on public repos leads to near-instant compromise
- The current mitigation (opt-in pre-tool-use hooks) requires users to already know about the risk and write their own detection logic — which defeats the purpose of preventing the issue in the first place
Comparison to Industry Standards
| Tool | Credential Safety |
|------|------------------|
| GitHub Actions | Built-in secrets context, automatic masking in logs |
| Kubernetes | Separate Secret resource, env var injection |
| Docker | Secret management in Compose, build-time secret mounts |
| AWS CDK | Secrets Manager integration, warns on hardcoded values |
| Claude Code | No detection, no placeholder syntax, no injection mechanism |
Environment
- Claude Code version: 2.1.128+
- OS: macOS
- Permission mode: bypassPermissions (but applies to all modes)
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗