[BUG] Sandbox suggestion from the docs breaks Bash's working dir

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?

Applying the sandbox rules suggested in the docs causes issues with working directory for Bash commands.

These are the rules in question:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

The offending line is "denyRead": ["~/"]. Removing this line consitently fixes the problem.

With the offending line present, each Bash commands seems to start from /home/username and then trigger a shell reset. This often breaks other commands (like git status or listing files in the directory).

The bug has two distinct cases.

Case 1: The project's directory is a direct child of the user's home directory

When the project dir is a direct child of /home/username (e.g., /home/username/some-project), Claude thinks it's in the home directory (i.e., /home/username) and most commands are broken (e.g., Claude fails when running ls or git status).

Here's what happens when you tell claude to run pwd:

❯ pwd # sanity check outside of claude
/home/username/some-project
❯ claude
 ▐▛███▜▌   Claude Code v2.1.87
▝▜█████▛▘  Sonnet 4.6 · Claude Max
  ▘▘ ▝▝    ~/some-project

❯ Run pwd

● Bash(pwd)
  ⎿  /home/username
  ⎿  Shell cwd was reset to /home/username/some-project

● /home/username

And here's what happens when you tell claude to run ls (verbose output):

❯ pwd # sanity check outside of claude
/home/username/some-project
❯ claude
 ▐▛███▜▌   Claude Code v2.1.87
▝▜█████▛▘  Sonnet 4.6 · Claude Max
  ▘▘ ▝▝    ~/some-project

❯ Run ls

● Bash(ls)
  ⎿  Shell cwd was reset to /home/username/some-project

● Bash(ls /home/username/some-project)
  ⎿  ls: cannot access '/home/username/some-project': No such file or directory

                                                                                            01:15 PM claude-sonnet-4-6
● The sandbox doesn't have read access to /home/username/some-project. You can run it yourself with ! ls in the prompt.

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  Showing detailed transcript · ctrl+o to toggle · ctrl+e to show all

Case 2: Project dir is not a direct child of the user's home directory

When the project dir is not a direct child of /home/username (e.g., /home/username/Projects/some-project):

• Claude first prints the home directory and then resets the shell to the project directory.
• Claude recognizes the project directory as the current PWD.
• Most commands work, but not all of them and not always.

Here's what happens when you tell Claude to run pwd:

❯ pwd
/home/username/Projects/some-project
❯ claude
 ▐▛███▜▌   Claude Code v2.1.87
▝▜█████▛▘  Opus 4.6 (1M context) · Claude Max
  ▘▘ ▝▝    ~/Projects/some-project

❯ run pwd

● Bash(pwd)
  ⎿  /home/username
  ⎿  Shell cwd was reset to /home/username/some-project

● /home/username/Projects/some-project.

As you can see, Clause settled on the pwd result in the end. But the incorrect first output and the shell reset indicate there's something wrong.

The final result isn't always correct and other commands often run into problems but I haven't documented the details. I think this should be enough for troubleshooting.

What Should Happen?

When I run claude inside a project directory (e.g., /home/username/some-project) and tell Claude to "run pwd," Claude should run pwd and return the correct project directory (/home/username/some-project) instead of the home directory (home/username), and it should not have to reset the shell.

Here's how that looks like.

❯ claude
 ▐▛███▜▌   Claude Code v2.1.87
▝▜█████▛▘  Opus 4.6 (1M context) · Claude Max
  ▘▘ ▝▝    ~/some-project

❯ run pwd

● Bash(pwd)
  ⎿  /home/username/some-project

● /home/username/some-project

This is the behavior I get when I remove "denyRead": ["~/"] from my sandbox config, confirming that this line is problematic.

Error Messages/Logs

Steps to Reproduce

1. Add the following settings to your ~/.claude/settings.json:

  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  },

1. Start claude from some project directory (e.g., ~/Projects/some-project).
2. Prompt claude with run pwd and see the mistake.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.87

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

This is not an LLM-assisted or an automatic report. I've written the entire thing by hand. Please allocate some human attention to the issue :)

I know the offending line is "denyRead": ["~/"] because everything works correctly when I remove it. I asked Claude to diagnose the problem and it identified it as a "bug in Claude code."

I know this is not:

• Terminal specific
• OS-specific
• Model specific

I've tried multiple terminals (Alacritty, Xfce terminal), OS-es (Arch, Ubuntu) and models (Sonnet, Opus).

Other people are running into this as well:

• https://news.ycombinator.com/item?id=47553495
• https://github.com/anthropics/claude-code/issues/17053 and several other issues, but they've all been closed for inactivity. I'm sure the bot will find them.

Here are my full settings.json