A / write root (Linux) or read root (macOS) no longer switches off the denies beneath it

[ronleizrowice-ant]

Summary

If / is in allowWrite, the Linux sandbox silently drops every write deny. denyWrite entries and the built-in protections (.git/hooks, .git/config, shell rc files, .mcp.json, .claude/commands, …) get no read-only bind, over a root that has just been bound writable. This PR makes the two checks responsible treat / as containing every path. macOS has the same slip for allowRead: ['/'] and gets the same fix.

Example

{ "filesystem": { "allowWrite": ["/"], "denyWrite": ["/home/u/.ssh"] } }

	bubblewrap arguments	result
Before	--bind / / and nothing for the denies	~/.ssh and <cwd>/.git/hooks are writable. Each deny is logged "not within allowed paths", at debug level only.
After	--bind / /, then a read-only bind (or placeholder) for each deny	the denies hold; the rest of the tree stays writable

Cause

"Is this deny path inside the write allowlist?" was written as

candidate === allowed || candidate.startsWith(allowed + '/')

For allowed === '/' the prefix is //, which no path starts with. Two places used that spelling:

• isWithinAnyAllowedWritePath decides whether a deny gets a bind at all.
• findSymlinkInPath decides whether a symlinked ancestor of a deny path gets the /dev/null mask that stops it being swapped for a real directory.

#502 added root-aware helpers (isAtOrUnder, isStrictlyUnder) and moved five sibling checks in the same function onto them. These two were missed.

Change

• Linux: both checks call isAtOrUnder.
• macOS: the block that re-emits a denyRead nested inside an allowRead directory (Seatbelt is last-match-wins) also compared with a + '/', so allowRead: ['/'] re-opened every denied path and no deny was re-emitted. It now uses isStrictlyUnder, and the macOS module's private copy of that helper delegates to the shared one, so the checks that were wrong now share one helper.
• Comments that described the old behaviour are corrected. No other logic changes.

Who sees a difference

• No / in allowWrite (Linux) or allowRead (macOS): nothing changes. For any other directory the helper is the same comparison the code spelled inline.
• allowWrite: ['/']: write denies now apply, including the built-in ones for the current directory. That is the documented behaviour. For built-in denies whose file does not exist, bubblewrap creates an empty placeholder on the host for the life of the command, as it already does under any other write root.
• filesystem.disabled: true: unaffected. In that mode the manager passes no write config to the backend, so this code does not run and the built-in protections stay off, as documented.
• Not behind a flag.

Configurations that now refuse to start

Turning the denies back on also turns on a start-up failure that main already has for every other write root. Until now it could not be reached under /, because every deny was skipped.

• The shape: allowWrite: ['/'], plus a denyWrite directory that contains the current directory and has some allowed write path beneath it. Through SandboxManager the default write paths (~/.claude/debug, ~/.npm/_logs, /tmp/claude) always count as allowed paths, so denyWrite: ['$HOME'] or denyWrite: ['/'] is enough. No read policy is needed.
• What happens: the denied directory is bound read-only, the built-in denies for files that do not exist yet (<cwd>/.gitconfig, <cwd>/.mcp.json and friends) still get placeholders, bubblewrap cannot create a placeholder inside a read-only mount, and it exits with Can't create file at <cwd>/.gitconfig: Read-only file system (the first placeholder it reaches). Every command fails.
• Before this PR that configuration started, with every deny silently off. Refusing to start is the safe direction, but it is a visible change for anyone who has it.
• Who fixes it: linux: collapse a read-deny glob to its covering directories, and mount every read deny where it really is #503 narrows the rule that keeps those placeholders, and Linux: pin ancestor directories of deny binds against rename #514 handles a root that is both allowed and denied. With either merged, these shapes start and the denies hold.
• The same applies when the current directory is not writable by the caller (root-owned, a read-only mount, or / itself for a non-root user): the placeholders cannot be created and the sandbox does not start.

Merge order

#514, #503 and #524 rework the same function, so please merge this first: it is small, and it deliberately avoids the lines they change. #503 and #524 still carry the old comparison and pick the fix up when they merge main. #514 already uses the same root-aware rule. It also goes one step further for a root that is both allowed and denied (it treats the paths beneath as covered, where this PR alone emits placeholders bubblewrap cannot create), so when #514 merges main it updates the second and third blocks of this PR's last / test to match.

Testing

Linux, bubblewrap 0.11.2.

• New cases, all failing on main and passing here:
  • a denyWrite file and directory that no other allow entry covers get their binds under a / root;
  • a symlinked ancestor of a deny path gets its mask;
  • the built-in denies under a / root: the ones that exist get binds, the absent ones get placeholders;
  • at runtime, the denied write fails and the rest of the tree stays writable;
  • macOS: a literal denyRead nested under allowRead: ['/'] is re-emitted.
• Two existing / assertions could not fail: they searched for --ro-bind / /, which the base read-only root mount always matches, so they passed whether or not the deny's own bind of / was emitted. They now count whole <flag> <source> <dest> triples, and were checked by removing the deny-side bind: both fail without it.
• The refuse-to-start shapes above were measured on both commits under bubblewrap 0.11.2, directly and through SandboxManager: main starts with no deny bind at all, this branch aborts, a cwd outside the denied directory starts on both, and a denied directory with no allowed path beneath it starts with its absent built-in denies skipped as covered.
• allowWrite: ['/'] + denyWrite: ['/'] with no read policy now also runs under bubblewrap: it boots, a read through the read-only root succeeds, and a write fails and leaves the host file unchanged.
• allowWrite: ['/'] + denyWrite: ['/'] with no read policy is pinned: exactly --ro-bind / /, --bind / /, --ro-bind / /, every per-path deny skipped, and the per-path denies come back as soon as a second allow entry or one read-deny directory exists.
• tsc, eslint and prettier clean on the changed files. Full npm test has the same failures as a clean main checkout on the same host (all environment-dependent), with five more tests passing. CI is green on all eight jobs.