Feature request: harness-level Bash-output secret redaction (3 leak incidents in 6 days, willing to contribute regex set + test suite)

Hi Anthropic team — sharing experience + asking about harness-level Bash-output redaction

First: thank you for Claude Code. We use it daily across a 10-repo ecosystem and it's transformed how we work. This is a constructive feature request from real production experience — open to contributing back whatever's helpful.

The pattern we've hit three times in six days

Working in Claude Code, secret values are leaking into our session transcripts via Bash tool output. Three confirmed incidents at one operator workstation in ~6 days:

• 2026-05-28 — A bash ${v:+x} value-surfacing idiom expanded a token into stderr
• 2026-05-30 — A directory-listing scan walked an old backups path and printed token-containing files
• 2026-06-03 — A diagnostic grep -E "(github|kagdaci)" ~/.npmrc printed an active GitHub Packages PAT (rotated immediately)

Each incident forced a credential rotation. None of these are exotic — they're shapes that came up during normal diagnosis work the model was asked to do.

Why PreToolUse hooks can only go so far

We've built a PreToolUse(Bash|PowerShell) hook (secret-tripwire.mjs at https://github.com/KAGDACI/byka-digital-business/blob/main/packages/byka-security-baseline/templates/claude-hooks/secret-tripwire.mjs) that refuses ~15 known-bad command shapes:

• File reads against credential stores (~/.npmrc, ~/.aws/credentials, ~/.git-credentials, ~/.netrc, ~/.docker/config.json, gh hosts.yml, ~/.ssh/id_*)
• grep (without -q/-l/-c) against those stores
• env-var dumps (printenv, env, bare set, Get-ChildItem env:)
• echo $SECRET_TOKEN and PowerShell $env:SECRET_* references
• Value-surfacing idioms like ${X:+y}${X:-z} and ${SECRET_TOKEN:+x}
• Predictable secret-emitting commands: gh auth token, aws configure get *secret*|*token*, wrangler secret list/get, vault kv get -field=, kubectl get secret -o (json|yaml|jsonpath), op read op://, gcloud auth print-access-token, az account get-access-token, doctl auth token

It works — most leaks get blocked. But it's a treadmill. A hook sees the COMMAND, not the OUTPUT. The classes it structurally can't catch:

1. Novel commands that happen to emit a secret. Every new CLI tool that surfaces credentials needs a new regex.
2. Indirect surfacing through unrelated commands. npm config ls -l dumps resolved .npmrc values. git config --get-all credential.helper may expose tokens. kubectl describe instead of get -o yaml works around the regex.
3. Output of legitimate write-intent commands. wrangler secret put NAME --text=<VALUE> is a WRITE, but the command line itself logs to transcript with the value inline.
4. Output of commands invoked by Claude on dynamic user request. When the operator asks Claude to "verify the registry is wired," Claude reasonably runs grep/cat/etc. A pre-block ruleset can't anticipate every legitimate cross-perimeter use.

What we think would help — harness-layer output redaction

A configurable stream filter that masks well-known secret patterns from captured stdout/stderr of Bash tool calls BEFORE the output is written to the transcript or sent back to the model. Honest pattern set (the canonical ones we've seen leak):

| Pattern | Mask |
|---|---|
| ghp_[A-Za-z0-9]{36} | ghp_<REDACTED> |
| gho_[A-Za-z0-9]{36} | gho_<REDACTED> |
| ghu_[A-Za-z0-9]{36} | ghu_<REDACTED> |
| ghs_[A-Za-z0-9]{36} | ghs_<REDACTED> |
| ghr_[A-Za-z0-9]{36} | ghr_<REDACTED> |
| github_pat_[A-Za-z0-9_]{82} | github_pat_<REDACTED> |
| xox[bopasr]-[A-Za-z0-9-]{10,} | xox*-<REDACTED> |
| AKIA[A-Z0-9]{16} | AKIA<REDACTED> |
| sk-[A-Za-z0-9]{20,} | sk-<REDACTED> |
| -----BEGIN (OPENSSH|RSA|DSA|EC|PGP) PRIVATE KEY-----[\s\S]+?-----END | <REDACTED PRIVATE KEY> |
| Bearer\s+[A-Za-z0-9._-]{20,} | Bearer <REDACTED> |
| (operator-configurable additions) | per-user |

Why this seems like a clean fit for the harness rather than every-operator's hook:

• Pattern set is conservative + well-known → near-zero false positives
• Output post-processing only → no impact on command behavior
• Opt-in via settings.json → operators stay in control
• Defense-in-depth → does NOT replace PreToolUse hooks; complements them
• Aligns with existing transcript-share redaction → if there's already logic for share-time redaction, this could share infrastructure

Honest tradeoff: redaction can mask output the operator actually wants (e.g., debugging a token format). Two ideas for that — both informational:

1. Operator-facing redaction event log (count + pattern, never the matched value)
2. Per-tool-call redaction: bypass flag — explicit opt-out for known-safe diagnostic sessions, surfaced to the model as "this output may contain unredacted secrets — handle with care"

Asks

1. Is this a gap you're already tracking? (No need to dig — yes/no is fine, helps us calibrate where to invest hook effort vs harness effort.)
2. If you'd consider building it: anything we can offer? Happy to share:

• Our regex set as a starting point (battle-tested against real leaks, not synthetic)
• The 93-test suite that covers the patterns + the false-positive class
• The 3 incident write-ups (with secrets redacted from the writeups themselves, of course)

Context on the asker

ByKA Insights — a small AI/automation consultancy. We're not enterprise — just an operator and an agent ecosystem trying to do supply-chain security well at small scale. Open to contributing whatever's useful from our limited operator-side know-how, in whatever form works for you (PR, design doc, regex spec, test cases, or just feedback on a design you're already exploring).

Thanks for considering, and thanks again for the tool.

— Kerim Agdaci (KAGDACI on GitHub)