[BUG] ENV_SCRUB=1 sandbox leaves persistent 0-byte placeholder files in cwd AND $HOME (.netrc, .bashrc, .gitconfig) — still in v2.1.211

Description

With CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1, every Claude Code run leaves behind persistent 0-byte placeholder files — 18 entries in the working directory and, additionally, credential/shell-config file names in $HOME (.netrc, .bashrc, .bash_profile, .bash_aliases, .profile, .zshrc, .gitconfig). They are not cleaned up on exit.

This extends #46165 (closed as not planned) and #17258 (closed as duplicate) with:

1. Still reproduces on v2.1.211 (latest as of 2026-07-16), CLI headless mode, no IDE.
2. A deterministic A/B: the env var alone flips the behavior (matrix below), confirming the community diagnosis in #46165.
3. A previously unreported, larger $HOME file set including .netrc and shell rc files — a 0-byte .netrc appearing in root's home is alarming in security scans and estate audits.
4. The files persist after the process exits (an earlier comment on #46165 observed create+delete per Bash invocation; on our hosts they leak permanently).

Environment

• Claude Code v2.1.211, native binary, CLI only (claude -p), no IDE
• Ubuntu 22.04, kernel 5.15, running as root on a VPS ($HOME=/root)
• CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 set in ~/.claude/settings.json env block (deliberately — we rely on subprocess env scrubbing for credential hygiene)

Reproduction (scratch HOME + scratch cwd, fully isolated)

mkdir -p /tmp/probe/home /tmp/probe/cwd && cd /tmp/probe/cwd
HOME=/tmp/probe/home CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 claude -p "say ok" --model haiku
ls -A /tmp/probe/cwd /tmp/probe/home

A/B matrix (v2.1.211, identical scratch env, prompt completes successfully in all cases)

| CLAUDE_CODE_SUBPROCESS_ENV_SCRUB | files created in cwd | files created in $HOME |
|---|---|---|
| 1 | 18 (list below), persist after exit | 12+ incl. .netrc, .bashrc, .gitconfig |
| 0 | none | none |
| unset | none | none |

cwd set (all 0 bytes): .env, .env.local, .env.development, .env.development.local, .env.test, .env.test.local, .env.production, .env.production.local, .gitmodules, .npmrc, .yarnrc, .yarnrc.yml, bunfig.toml, package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, plus empty node_modules/.bin/.

additional $HOME set (all 0 bytes): .netrc, .bashrc, .bash_profile, .bash_aliases, .profile, .zshrc, .gitconfig, .bunfig.toml, .npmrc, .yarnrc, .yarnrc.yml.

The set is recognizably the sandbox's sensitive-file deny list — the placeholders appear to be created as mask/mount targets when the real files don't exist, and are then left behind.

Real-world impact we hit

• The 0-byte scaffold set was accidentally committed into a project repo (an April boundary commit picked them up) and confused dead-code audits for months.
• A batch landed in a data directory that happened to be a session cwd, and was repeatedly flagged by estate/hygiene sweeps.
• Deleting them is futile — the next session recreates them within minutes on a busy host.

Suggested fix

Create the mask placeholders under a private location (e.g. $CLAUDE_CONFIG_DIR/sandbox-masks/ or the session tmpdir) and bind-mount from there, instead of materializing them in the user's cwd/$HOME; or track which placeholders the sandbox itself created and unlink them on session exit. Either way, ENV_SCRUB=1 (a security-positive setting) should not have filesystem-pollution side effects that push users toward turning it off.