›_ Claude Code Issues
Claude Code Issues / #17087

[BUG] Claude Code creates empty read-only dotfiles in working directory during Bash tool execution

Resolved 💬 26 comments Opened Jan 9, 2026 by zerbiniandrea Closed Feb 6, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

OS: Arch Linux 6.18.3-arch1-1
Shell: zsh

Description
During Bash tool execution, Claude Code creates empty (0 byte), read-only (-r--r--r--) dotfiles in the current working directory:

  • .bashrc
  • .bash_profile
  • .gitconfig
  • .gitmodules
  • .profile
  • .ripgreprc
  • .zprofile
  • .zshrc

All files are created at the exact same millisecond.
Reproduces consistently across all directories and persists even after full uninstall/reinstall of Claude Code.

Evidence:

❯ stat .bashrc      
  File: .bashrc
  Modify: 2026-01-09 11:53:46.383975800 +0100
  Change: 2026-01-09 11:53:46.383975800 +0100
  Birth: 2026-01-09 11:53:46.383975800 +0100

❯ ls -la .bashrc
    -r--r--r-- 1 zerbi zerbi 0 Jan  9 11:53 .bashrc

Debug log shows Bash tool execution at exact same timestamp:

2026-01-09T10:53:46.150Z [DEBUG] executePreToolHooks called for tool: Bash

It's happening for almost any command, e.g. git status in this case.

Additional findings:

  1. Direct shell execution of git status → no dotfiles created
  2. Commands typed in Claude Code's integrated terminal → no dotfiles created
  3. Commands executed via the Bash tool (agent tool calls) → dotfiles created immediately

The files are only created when commands run through the Bash tool's execution path, not through direct shell invocation.

What Should Happen?

It should definitely not create those files.

Steps to Reproduce

  1. Start Claude Code in any directory
  2. Ask for the execution of any Bash command (e.g., git status)
  3. Check for newly created dotfiles

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not sure about the version number, but everything was working correctly up to yersterday

Claude Code Version

2.1.2 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

View original on GitHub ↗

26 Comments

tomasfejfar · 6 months ago

It might be related to the use of /sandbox due to the weird permission on the files . 

    crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .bash_profile
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .bashrc
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .claude
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .git
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .gitconfig
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .gitmodules
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .idea
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .mcp.json
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .profile
     crw-rw-rw- 1 nobody      nogroup     1, 3 Jan  5 10:43 .ripgreprc

I'm on Ubuntu, using bubblewrap 0.9.0 for the sandboxing, Claude Code 2.1.2.

zerbiniandrea · 6 months ago

Can confirm that this happens only with sandbox on

psinger · 6 months ago

Can confirm the same, pretty annoying

wellcaffeinated · 6 months ago

Found this today too. Can confirm disabling sandbox seemed to do the trick.

ariel-frischer · 6 months ago

Confirmed - sandboxing enabled is causing this. On Arch Linux. Claude Code v2.1.3

archer-eric · 6 months ago

workaround

The following PostToolUse hook is working pretty well in my environment to clean up the spurious files after the Bash tool completes running in the sandbox.

claude-code-sandbox-bash-tool-issue-17087.sh

See the comments for installation instructions. Don't run code from random strangers without careful review. Have Claude Code build you your own hook based on this idea.

As written, it logs every run to a file in the home directory to remind me that it needs to be removed when the bug is fixed.

There can still be unfortunate interactions with the files while the Bash tool is running. For example:

  1. In a long running command, Claude Code itself can even notice them and show a warning like:

``
Found 1 invalid settings file · /doctor for details
``

  1. bwrap reports an error in some Bash tool commands in the sandbox (note: .claude is a file created by the bug):

``
> ● Bash(git add [ELIDED] \…)
⎿  Error: Exit code 1
bwrap: Can't mkdir parents for
/[ELIDED]/.claude/settings.json: Not a directory
``

jancellor · 6 months ago

I confirm this happens on Ubuntu 24.04. From what I can tell, CC is trying to mask sensitive files by using a bwrap call like:

bwrap ... --ro-bind /dev/null /home/me/test/.bash_profile ...

This causes bwrap to creating a zero byte file. CC needs to conditionally apply the flags depending on whether the files exist and apply the binding to the home directory not the current directory.

la-j · 6 months ago

This is caused by the sandbox runtime, issue is here: https://github.com/anthropic-experimental/sandbox-runtime/issues/85

archer-eric · 5 months ago

Looks like good news may be coming:
https://github.com/anthropic-experimental/sandbox-runtime/issues/85
was just closed with
https://github.com/anthropic-experimental/sandbox-runtime/pull/91

archer-eric · 5 months ago

This is fixed for me on Ubuntu 24.04 as of Claude Code v2.1.31 (or possibly a bit earlier).

Tedpac · 5 months ago

This issue is still occurring on Claude Code v2.1.41 (I have just updated).

erannave · 5 months ago

Still happening on v2.1.41, Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2). Same empty read-only files created in the working directory: HEAD, config, hooks, objects, refs, .bash_profile, .bashrc, .gitconfig, .gitmodules, .profile, .ripgreprc, .zprofile, .zshrc.

konstin · 5 months ago

There seems to be a regression, the problem was solved for me but has reappeared this morning.

appaquet · 5 months ago

Same for me, v2.1.41 re-introduced the problem...

I think the fix for this that got merged here https://github.com/anthropic-experimental/sandbox-runtime/pull/91 got reverted/reworked in https://github.com/anthropic-experimental/sandbox-runtime/pull/126 which reintroduced the problem?

Edit: still broken in v2.1.42. Pinned to v2.1.39 for now

kwaegel · 4 months ago

Can someone re-open this bug? I feel like this isn't going to get fixed if it's left closed, and newer bugs are getting closed as duplicates of this one.

drmercer-lucid · 4 months ago

Here is the new bug in sandbox-runtime that re-introduced this problem: https://github.com/anthropic-experimental/sandbox-runtime/issues/139

aaron-manning · 4 months ago

Still reproducing on the latest version (Linux, sandbox enabled). Running a web search or any Bash tool execution creates 0-byte read-only dotfiles in the project root:

.bash_profile, .bashrc, .gitconfig, .gitignore, .gitmodules, .idea, .mcp.json, .profile, .ripgreprc, .vscode, .zprofile, .zshrc, config, HEAD, hooks, objects, refs

Agreeing with the request to re-open — this regressed after the sandbox-runtime rework (PR #126) and the upstream tracking issue is sandbox-runtime #139. Closing newer reports as dupes of a closed issue means this falls through the cracks.

Current workaround is adding all of these to .gitignore.

AgainPsychoX · 4 months ago

I have the same issue, v2.1.59.

dfaivre-pcs · 4 months ago

Still reproducing on Claude Code v2.x (Linux, WSL2, sandbox enabled).

Environment:

  • OS: Linux 6.6.87.2-microsoft-standard-WSL2
  • Shell: bash
  • Sandbox: enabled via .claude/settings.json

Phantom files created in project root:
.bash_profile, .bashrc, .gitconfig, .gitmodules, .idea, .mcp.json, .profile, .ripgreprc, .zprofile, .zshrc, HEAD, config, hooks, objects, refs, .claude/skills

All 0-byte, read-only (444). Created on first Bash tool execution in the session.

Additional observations:

  • The files include bare git repo internals (HEAD, objects, refs, hooks, config) — likely from the sandbox deny list for .git/ paths being resolved relative to CWD instead of the actual .git/ directory
  • .claude/skills is also created as a phantom file
  • Files cannot be removed from inside the sandbox (chmod fails with "Read-only file system"), but can be removed outside it (chmod u+w && rm)
  • They persist after the session ends (not cleaned up automatically)

Workaround: Remove outside the sandbox session with chmod u+w <files> && rm <files>. Adding them to .git/info/exclude hides them from git status but doesn't prevent creation.

maze88 · 4 months ago

bumping; please re-open!

dfaivre-pcs · 4 months ago
bumping; please re-open!

I think this might be fixed in 2.1.69 (as of today) 🤞

kwaegel · 4 months ago

~2.1.69 seems to be working so far. Odd that the upstream sandbox issue is still open, though.~

Nope, v2.1.69 is still broken.

Cleroth · 4 months ago

Seems it deletes the old files as well.

AgainPsychoX · 4 months ago

Still an issue in 2.1.70.

Also, very first bash tool call per session fails with:

     Error: Exit code 1                                                                                               
     /bin/bash: line 1: /tmp/claude-1000/cwd-a294: Read-only file system

It was like this for long time.

So sad the sandbox sucks...

kwaegel · 4 months ago

Claude 2.1.75 managed to break itself several times today with the phantom files.

github-actions[bot] · 3 months ago

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.