[BUG] Linux sandbox: filesystem.allowRead on a symlink inside a denyRead directory has no effect

Environment

• Claude Code 2.1.283
• Linux (bubblewrap sandbox)

Setup

"sandbox": {
  "filesystem": {
    "denyRead": ["~/"],
    "allowRead": ["~/.aws", "~/keys/aws/.aws", "~/.local/share/mise"]
  }
}

~/.aws is a symlink to ~/keys/aws/.aws. ~/.local/share/mise is a real directory.

What happens

Inside the sandbox:

• ~/keys/aws/.aws (the link target) is readable.
• ~/.local/share/mise (a real directory) is readable.
• ~/.aws (the symlink) does not exist: ls ~/.aws → No such file or directory.

The resolved sandbox config shown to the model lists /home/<user>/.aws in allowWithinDeny, so the entry is accepted but not applied. Tools that use the symlinked path (aws reads ~/.aws/config and ~/.aws/sso/cache) can't find their files.

The same happens with ~/.config/zsh, which GNU Stow deploys as a symlink into a dotfiles repo.

Expected

An allowRead path that is a symlink under a denyRead directory should be visible in the sandbox, e.g. recreated as a symlink when its target is also allowed, or bound at the link path. At minimum, the docs should say that allowRead entries must be real directories on Linux.

Impact

Dotfile managers (GNU Stow, chezmoi symlink mode, etc.) deploy config directories as symlinks, so a denyRead: ["~/"] + allowRead setup can't allow those configs back in. The only workaround is restructuring the home directory so the allowed paths are real directories.