A database command may run once. The string retained to approve it next time can outlive that execution in a settings file and Git history. Execution permission and information retention are separate decisions.
Apiiro's November 5 research, updated November 8, reports a path in which Claude Code approval rules retain commands containing secrets. We distinguish the company's exposure counts from Git behavior tested locally.
Fix the denominator before reading the count
| Research item | Apiiro's count | Our verification boundary |
|---|---|---|
| Public settings.local.json files | 104,185 | Read the report; did not recollect |
| Files classified as containing real secrets | 1,122 | Vendor classification; not independently adjudicated |
| Wider scope including history and other artifacts | 1,994 repositories, 2,539 secrets | A different denominator from the file count above |
Source: How many / Method and limits. A sample of public files cannot establish an exposure probability for all users or private repositories. We did not download exposed credentials or test their validity.
The mechanism can be considered separately from its prevalence: a sensitive command is recorded, its file becomes tracked, and that artifact is shared. Do not generalize the behavior to every automatic execution mode.
Each boundary needs its own decision
Task requiring a secret
│ supply execution value
▼
Shell command / tool input
│ retain for reuse
▼
Approval rule / transcript / work note
│ Git tracking or packaging
▼
History / clones / deployment artifacts
This is CodeBridge's threat model, not a claim that every version of every tool follows this sequence. A value needed at the first stage may be unnecessary to readers at the last. Decide separately whether an agent can do the work and where records of that work belong.
An environment-variable reference can reduce literal secrets in a command. It does not prevent shell tracing, debug logs, output or tool-input capture from recording the value. “We used an environment variable” is not a complete artifact policy.
Ignoring a file does not undo tracking
This boundary can be checked without running Claude Code. In a disposable repository, we staged an empty JSON file before adding an ignore rule.
1. Create an empty temporary Git repository
2. Write {} to .claude/settings.local.json
3. git add that file
4. Add its path to .gitignore
5. Check git ls-files and git check-ignore --no-index separately
Requires Node.js 18 or later and Git. From this project's root, run node docs/editorial/2026-11-08/evidence/tracked-ignore.mjs. Actual output:
ignore rule matches: true; file remains tracked: true
Empty synthetic JSON only; no Claude Code or real credentials used.
An ignore rule's presence and a file's untracked status are different facts. The experiment uses an empty file to check Git semantics. It does not independently reproduce the agent behavior or exposure counts in Apiiro's report.
Keep the secret out of the inspection report
Start with tracking status rather than printing file contents. These read-only checks show filenames and commit metadata for the path, without its contents:
git ls-files -- .claude/settings.local.json .claude/settings.json
git log --format='%h %cs' -- .claude/settings.local.json
They do not require installing the agent. Empty output is not proof of no exposure: other branches, filenames and archives are outside these checks. We provide no results from running them against a production repository.
Inspect contents with the organization's approved secret scanner. Reports should retain locations and types without copying secret values. GitHub's secret scanning documentation describes history scanning and immediate credential rotation after detection. Check the detector coverage and organization settings separately.
Revoke access before treating deletion as resolution
Deleting or untracking a published value does not invalidate it in existing copies. Revoke or rotate it at the issuing system, transition dependent services and inspect usage records. Then fix tracking and retention policies so the same path does not recur.
Manage execution permission, recording minimization, staged/push checks and post-exposure response as separate controls. Passing one does not justify omitting the others. Reducing approval interruptions and controlling information lifetime are independent engineering tasks.
Background: Agent security and sandboxes.