Sandbox bind-mounts /dev/null device nodes in working directory, breaking Python build tools

Summary

The Claude Code sandbox creates /dev/null character device node bind-mounts over common dotfile paths directly inside the working directory. These device nodes are picked up by Python build tools (hatchling, setuptools) when building sdists, and pip 26.1+ rejects the resulting tarballs because they contain special files.

Environment

• Claude Code: 2.1.123
• OS: Fedora 43 (Linux 6.19.11-200.fc43.x86_64)
• Python: 3.12 / 3.14
• pip: 26.1

Reproduction

1. Open a Python project that uses hatchling (or any PEP 517 build backend) with tox
2. Run tox or any command that builds an sdist from the project
3. The sdist includes device nodes, and pip rejects it:

``
ERROR: Invalid member in the tar file ...: '.bash_profile' is a special file
``

Root Cause

The sandbox bind-mounts /dev/null (from devtmpfs) over these paths in the working directory:

.bash_profile, .bashrc, .profile, .zprofile, .zshrc,
.gitconfig, .gitmodules, .env, .mcp.json, .ripgreprc,
.vscode, .idea

Verified via mount | grep devtmpfs | grep "$PWD" — all 12 entries show up as devtmpfs bind mounts.

These don't exist on the actual filesystem — they're only visible inside the sandbox namespace. However, build tools like hatchling see them as real files and include them in the sdist tarball. pip 26.1's stricter tar validation (PEP 706) then rejects the tarball containing character device nodes.

Expected Behavior

The sandbox should not create device nodes inside the working directory where they can interfere with build tools. Possible alternatives:

• Mount them outside the project tree (e.g., in a parent or overlay namespace)
• Use an overlay filesystem so the device nodes aren't visible to userspace tools scanning the directory
• Add them as entries the build backend won't traverse

Workaround

Running build commands (make linter, tox, etc.) from a terminal outside Claude Code works fine since the bind mounts only exist inside the sandbox.