CWD is polluted with empty boundary files at every session start (package.json, yarn.lock, .env.*, etc.)
Summary
Every claude session creates 10+ empty (0-byte) files and a node_modules/ directory in the current working directory (CWD) at startup. These cannot be disabled through any documented setting, including sandbox.enabled: false.
Environment
- Claude Code version:
2.1.116 - OS: Linux 6.6.87.2-microsoft-standard-WSL2 (Ubuntu on WSL2)
- Shell: bash
Reproduction
mkdir /tmp/repro && cd /tmp/reproclaude(any session, even with no prompt)ls -lain CWD
Expected
CWD remains untouched unless the user explicitly creates files.
Actual
The following 0-byte files and directory are created at startup (all with the same nanosecond timestamp, indicating a single programmatic burst):
.env
.env.development
.env.development.local
.env.local
.env.production
.env.production.local
.env.test
.env.test.local
.gitmodules
.npmrc
.yarnrc
.yarnrc.yml
bunfig.toml
package.json
package-lock.json
pnpm-lock.yaml
yarn.lock
node_modules/.bin/ (empty directory)
Additionally, bind-mounts (character devices owned by nobody:nogroup) are placed over common user config files (.bashrc, .zshrc, .gitconfig, .mcp.json, .idea, .vscode, scripts, etc.) at initial CWD entry.
Hypothesis (unverified)
The Claude Code binary appears to be compiled with bun build --compile. strings on the installed binary reveals:
- JavaScriptCore / Bun runtime symbols (
JSLexicalEnvironment_variables,JSC::FTL::...) - The exact filenames above embedded as literals
- Bun compile flags:
--no-compile-autoload-dotenv,--no-compile-autoload-bunfig,--no-compile-autoload-package-json
This suggests the embedded Bun runtime's autoload discovery (or a related isolation layer) is responsible, but the precise creation path is opaque to end users.
Why this matters
- Users expect
cd ~/my-workspace && claudeto leave the workspace untouched. - The empty files conflict with real project initialization (
npm init,bun init) because they already exist. - Users must add all ~18 filenames to
.gitignoreto prevent pollution in version control. - Several of the files (
.env*) have security implications — their presence can change how other tools (Next.js, Vite, Docker Compose) interpret the directory.
Workarounds tried
- Setting
"sandbox": { "enabled": false }in both~/.claude/settings.jsonand./.claude/settings.local.json— no effect, files still created. - Disabling all plugins — no effect.
- Custom
SessionStarthooks — cannot prevent, only react.
Request
Please provide one of:
- A documented setting to disable boundary-file creation (e.g.
"workspace": { "isolateCwd": false }). - An environment variable (e.g.
CLAUDE_CODE_NO_CWD_MARKERS=1). - Runtime CLI flags that pass through to the embedded Bun's
--no-compile-autoload-*family. - At minimum, documentation explaining which files are created, why, and that users should run
claudeonly in disposable or dedicated directories.
Additional info
All files created in a single syscall burst — example stat output:
2026-04-21 11:15:14.378440534 +0900 .env
2026-04-21 11:15:14.378440534 +0900 .env.development
2026-04-21 11:15:14.378440534 +0900 package.json
2026-04-21 11:15:14.378440534 +0900 bunfig.toml
...
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Unexpectedly mutating the working directory at session start is a serious local-integrity problem, especially when the files look like meaningful project boundary/config artifacts (
.env*,package.json, lockfiles,node_modules/). Those filenames are not harmless temp names, they are names tools and humans interpret as real project structure.That means the bug has blast radius beyond clutter:
The fact that all files arrive as a single 0-byte burst is useful because it points to a startup routine, not organic user/task behavior. A coding tool should not be fabricating project-significant boundary files in CWD just by launching.
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.