[BUG] Claude Code creates 17+ empty files (.env, .npmrc, package.json, node_modules) in working directory on every startup

[NexusOne23]

Description

Since updating to ~v2.1.98, Claude Code creates 17+ empty 0-byte files and an empty node_modules/.bin/ directory in the working directory on every startup. This happens via the VSCode/VSCodium extension — the native-binary/claude process creates these files before any user interaction.

Files created (all 0 bytes, all within <1ms)

.env, .env.local, .env.development, .env.development.local,
.env.test, .env.test.local, .env.production, .env.production.local,
.npmrc, .yarnrc, .yarnrc.yml, .gitmodules,
bunfig.toml, package.json, package-lock.json,
pnpm-lock.yaml, yarn.lock, node_modules/.bin/ (empty dir)

Environment

• OS: Fedora 43, SELinux enforcing, hardened desktop
• IDE: VSCodium 1.99.x (RPM, not Flatpak)
• Claude Code: 2.1.98 → 2.1.100 (bug persists across updates)
• Extension: anthropic.claude-code-2.1.100-linux-x64
• Working directory: ~/Downloads (configured in VSCodium)
• Shell: Bash 5.2

Reproduction

1. Install Claude Code extension in VSCode/VSCodium
2. Set working directory to any folder (e.g. ~/Downloads)
3. Start VSCode/VSCodium
4. Observe: 17 empty files + node_modules/.bin/ appear in the working directory

Confirmed with inotifywait:

11:53:07 /home/user/Downloads/.npmrc CREATE
11:53:07 /home/user/Downloads/.yarnrc CREATE
11:53:07 /home/user/Downloads/.yarnrc.yml CREATE
11:53:07 /home/user/Downloads/bunfig.toml CREATE
11:53:07 /home/user/Downloads/package.json CREATE
11:53:07 /home/user/Downloads/.gitmodules CREATE
11:53:07 /home/user/Downloads/package-lock.json CREATE
11:53:07 /home/user/Downloads/yarn.lock CREATE
11:53:07 /home/user/Downloads/pnpm-lock.yaml CREATE
11:53:07 /home/user/Downloads/.env CREATE
... (all 17 files at same second)
11:53:07 /home/user/Downloads/node_modules CREATE,ISDIR

Files are also created in ~ (home root), not just the working directory.

Process responsible

/home/user/.vscode-oss/extensions/anthropic.claude-code-2.1.100-linux-x64/resources/native-binary/claude
  --output-format stream-json --verbose --permission-mode acceptEdits ...

Additional finding: Sandbox regression

Before ~v2.1.98, the sandbox worked fine without socat installed. After updating, the sandbox fails with Sandbox failed to initialize. unless socat is explicitly installed (sudo dnf install socat). The error message gives no hint that socat is missing.

After installing socat, the sandbox also requires a .claude/ directory in the working directory to exist — otherwise bwrap fails with Can't mkdir /path/.claude: Not a directory.

Timeline:

• Before v2.1.98: Sandbox works, no socat needed, no ghost files
• After v2.1.98: Sandbox broken (needs socat), ghost files on every startup

Impact

• Pollutes working directories with JS ecosystem files on a system that has no Node.js/npm installed
• Confuses users who see unexpected files appear
• Can interfere with git repositories (files show as untracked)
• node_modules directory is particularly alarming on a hardened system

Current workaround

# Bash alias to clean up
alias ccclean='rm -rf ~/{.env,.env.*,.npmrc,.yarnrc,.yarnrc.yml,bunfig.toml,package.json,package-lock.json,pnpm-lock.yaml,yarn.lock,.gitmodules,node_modules} ~/Downloads/{.env,.env.*,.npmrc,.yarnrc,.yarnrc.yml,bunfig.toml,package.json,package-lock.json,pnpm-lock.yaml,yarn.lock,.gitmodules,node_modules} 2>/dev/null'

Expected behavior

Claude Code should not create any files in the user's working directory on startup. If these files are needed for internal operation, they should be in ~/.claude/ or a temp directory, not the workspace root.

[NexusOne23]

Update: This bug is not VSCodium-specific. The same empty files are also created when launching claude directly from the terminal (CLI mode, no IDE involved).

Tested with Claude Code CLI v2.1.100:

claude --version  # 2.1.100
# → same 17 empty files appear in the current working directory

So the root cause is in the claude binary itself, not in the VSCode/VSCodium extension layer. The extension just triggers it by spawning the binary on IDE startup.

[NexusOne23]

Update: Root cause identified with inotifywait

The sandbox itself creates AND deletes these files on every single Bash tool invocation:

12:05:17 CREATE /home/user/Downloads/bunfig.toml
12:05:17 CREATE /home/user/Downloads/package.json
12:05:17 CREATE /home/user/Downloads/.env
12:05:17 CREATE /home/user/Downloads/.env.local
... (17 files + node_modules/)
12:05:17 DELETE /home/user/Downloads/bunfig.toml
12:05:17 DELETE /home/user/Downloads/package.json
12:05:17 DELETE /home/user/Downloads/.env
12:05:17 DELETE /home/user/Downloads/.env.local
... (all 17 + node_modules/ deleted)

All CREATE + DELETE events happen within the same second — this is the sandbox initialization/teardown cycle.

The bug is: On IDE startup (first sandbox init), if anything goes wrong (race condition, timeout, missing dependency like socat), the DELETE phase never executes and the files persist in the working directory.

This also means these files are created and deleted on every Bash tool call during normal operation — they're just invisible because the cycle completes. The real issue is the non-atomic cleanup on startup failure.

Captured with: inotifywait -m -e create -e delete ~/Downloads/ while triggering a Bash tool call from the Claude Code extension.

[Erikeo29]

Additional findings on WSL2 + root cause: CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is the trigger

Reproducing this bug on a completely different environment (WSL2, Ubuntu 22.04, CLI only, no IDE), I can confirm the issue persists on v2.1.101 (latest as of 2026-04-11) and identify a missing detail: CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 is the trigger for the sandbox creating these placeholder files.

Environment

• OS: WSL2 Ubuntu 22.04.5 LTS on Windows 11
• Kernel: 5.15.167.4-microsoft-standard-WSL2
• Claude Code: v2.1.101 (native install, ~/.local/bin/claude)
• Model: Opus 4.6
• IDE: None (pure CLI usage via Windows Terminal → WSL2 bash)

Key finding: the env var trigger

The sandbox behavior is gated by CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1. When this env var is set, CC launches a bwrap sandbox at startup that creates the 17-18 placeholder files. When unset, no sandbox → no placeholder files → no bug.

On my system, this variable was set in ~/.bashrc on 2026-04-04 following the v2.1.83+ release notes recommending it as a defense against subprocess credential exfiltration. Empty files started appearing on 2026-04-10, which aligns exactly with the CC auto-update from v2.1.98 → v2.1.100 (via v2.1.99). This strongly suggests the regression was introduced in v2.1.99 with the PID namespace isolation feature, combined with the pre-existing ENV_SCRUB variable.

Evidence from /proc/1/cmdline inside a sandboxed CC session

bwrap
--new-session
--die-with-parent
--ro-bind / /
--bind /home /home
...
--ro-bind /dev/null /home/user/.bash_login
--ro-bind /dev/null /home/user/.bash_logout
--ro-bind /dev/null /home/user/.zprofile
--ro-bind /dev/null /home/user/.zshenv
--ro-bind /dev/null /home/user/.zlogin
--ro-bind /dev/null /home/user/.zlogout
--ro-bind /home/user/project/package.json /home/user/project/package.json
--ro-bind /home/user/project/.env /home/user/project/.env
--ro-bind /home/user/project/.env.local /home/user/project/.env.local
...

Two patterns visible:

• --ro-bind /dev/null <file> for files that should be "invisible" (non-existing shell startup files). Since --ro-bind requires the target to exist, CC creates the file first, then mounts /dev/null on top. The underlying empty file persists even after the mount is released.
• --ro-bind <file> <file> (self-bind read-only) for files like .bashrc that already exist - this is harmless since it doesn't create anything new.

The leak comes from the first pattern: the "mount point creation step" creates real files on disk that outlive the sandbox.

Also visible via mount | grep .env:

/dev/sdc on /home/user/project/.env type ext4 (ro,nosuid,nodev,...)
/dev/sdc on /home/user/project/package.json type ext4 (ro,nosuid,nodev,...)
none on /home/user/project/.github type devtmpfs (ro,nosuid,nodev,...)

Workaround (confirmed working)

Disable the env var in ~/.bashrc:

# export CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1

After applying this + a clean CC session restart, no new placeholder files are created in fresh directories. Tested empirically:

• Before: 62 empty placeholder files scattered across 3 directories (17-18 per dir)
• After: 0 new files

Trade-off: loses the subprocess credential scrubbing protection. For users who don't run subprocess code that might exfiltrate credentials (most R&D / scientific computing users), this is an acceptable temporary trade-off.

⚠ WSL2-specific gotcha when applying the workaround

Simply commenting out the env var in ~/.bashrc is not enough in WSL2. The parent bash shell caches the exported variable from its initial .bashrc sourcing, and neither source ~/.bashrc nor exit-then-relaunch-CC clears it. You need one of:

1. Close the terminal window completely (the X button) to force a fresh bash shell to re-read .bashrc
2. Or wsl --shutdown from PowerShell on Windows, to force restart the WSL2 init process
3. Or unset CLAUDE_CODE_SUBPROCESS_ENV_SCRUB in the parent shell before launching CC

In my testing, wsl --shutdown was required because WSL2 persists env vars in the init process between terminal windows. Without this step, CC launched from a "stale" terminal will inherit ENV_SCRUB=1 from the parent and the sandbox will still activate.

This gotcha would be worth mentioning in any documentation about the workaround.

Secondary impact: breaks Node.js stop hooks from community plugins

The placeholder package.json files cause ERR_INVALID_PACKAGE_CONFIG errors in any Node.js-based hook or plugin that walks the parent directory tree. Observed on the hook-sound-notifications@dev-gom-plugins community plugin: its SessionEnd hook runs a Node.js script that fails on every CC exit with:

Error: Invalid package config /home/user/package.json.
    at shouldUseESMLoader (node:internal/modules/run_main:92:16)
Node.js v22.17.1 {
  code: 'ERR_INVALID_PACKAGE_CONFIG'
}

Root cause: Node walks up from the script location, finds the 0-byte package.json placeholder in ~, and tries to parse it to determine ESM vs CommonJS module type. Empty content ≠ valid JSON → crash.

Any Node.js-based plugin, hook, or command in the CC ecosystem that reads nearest-parent package.json will break in a sandboxed session. This extends the blast radius of the bug beyond "just cosmetic file pollution" to "plugin ecosystem compatibility issue".

Summary for triage

• Reproducible on different platform : WSL2 Ubuntu 22.04, CLI only (no IDE), confirms the original Fedora/VSCodium report
• Latest version affected : v2.1.101 (as of 2026-04-11)
• Trigger identified : CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 env var
• Regression window : v2.1.99 (PID namespace isolation introduced)
• Working workaround : unset the env var (with WSL2 gotcha noted above)
• Secondary impact : breaks Node.js plugin stop hooks via ERR_INVALID_PACKAGE_CONFIG

Hope this helps narrow down the code path for the fix. Happy to provide more diagnostics if needed (e.g., strace on CC startup, full mount output, etc.).

[NexusOne23]

Confirmed: Removing ENV_SCRUB from settings.json resolves the issue

Environment: Fedora 43, SELinux enforcing, VSCodium RPM, Claude Code v2.1.101, Bash 5.3

Confirming @Erikeo29's root cause analysis. On our system, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB was set in ~/.claude/settings.json (not .bashrc):

{
  "env": {
    "CLAUDE_CODE_SUBPROCESS_ENV_SCRUB": "1"
  }
}

Before removal:

• 17+ ghost files created in ~/Downloads/ and ~/ on every startup and Bash tool invocation
• ccclean alias required after every session

After removal:

• Zero ghost files after VSCodium restart
• Bash tool works normally — no sandbox errors, no file pollution
• Verified with: ls -la ~/Downloads/.env ~/Downloads/package.json ~/Downloads/.npmrc 2>/dev/null → nothing

Security impact of disabling: Negligible for OAuth users. ENV_SCRUB protects against credential exfiltration from subprocess environments (strips ANTHROPIC_API_KEY, cloud provider tokens, etc.). Users authenticating via OAuth (no API key in env) with no cloud credentials in environment variables lose no practical protection by disabling this.

Note for triage: This is a second configuration path — the variable can be set in ~/.claude/settings.json under env, not just in shell rc files. Both paths trigger the same bwrap mount-point leak. The fix should account for both.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.