[BUG] Sandbox cwd tracking error persists/regressed in v2.1.29 (WSL2)

Resolved 💬 1 comment Opened Feb 12, 2026 by JasonBroderick Closed Feb 16, 2026

Related Issue

This is a follow-up to #11480 which was marked completed on Dec 6, 2025, but the issue persists (or has regressed) in v2.1.29.

Bug Description

When sandbox mode is enabled, every bash command shows exit code 1 with a read-only file system error, despite the actual command succeeding:

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

[actual command output - successful]

The error occurs on "line 4" during bash initialization, before the user's command executes. Commands complete successfully but the error noise is confusing and makes it appear commands are failing.

Root Cause (from #11480)

The bash integration writes CWD tracking files to /tmp/claude-{uid}/cwd-{random}, but the sandbox only allows writes to /tmp/claude/. These paths don't match, so the sandbox correctly blocks the write, causing the error.

Environment

  • Claude Code Version: 2.1.29
  • OS: Ubuntu on WSL2 (6.6.87.1-microsoft-standard-WSL2)
  • bubblewrap version: 0.9.0
  • socat: installed

Sandbox Configuration

{
  "sandbox": {
    "enabled": true,
    "autoAllowMode": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowedWritePaths": ["${CWD}", "/tmp"]
    }
  }
}

Reproduction Steps

  1. Install bubblewrap and socat on WSL2
  2. Enable sandbox mode via /sandbox
  3. Run any bash command (e.g., ls, uname -a)
  4. Observe exit code 1 error despite command succeeding

Expected Behavior

CWD tracking should write to a path the sandbox allows (e.g., ${TMPDIR}/cwd-{id} which resolves to /tmp/claude/cwd-{id}).

Workaround

None currently. The errors are cosmetic but confusing, especially when reviewing command output.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗