fix(sandbox): allow realpath(cwd) so bun run/bunx work in enforcing workspaces

[pds]

Fixes #35.

Problem

In an enforcing workspace, bun run <script> and bun x <pkg> fail at startup with:

error loading current directory
error: An internal error occurred (CouldntReadCurrentDirectory)

More generally, anything that canonicalizes the cwd with realpath(3) fails — which includes the Bun-compiled agent CLIs' bun run/bunx subprocesses and any Husky/git hook that uses bunx.

Root cause

render_profile allows file-read-metadata + file-test-existence globally, but file-read* (which includes file-read-data, i.e. opening a directory) only on the workspace, runtime, system roots, and (literal "/"). The workspace's intermediate ancestor directories (/Users, /Users/<me>, … down to the workspace's parent) get only metadata/existence.

realpath(3) on the cwd has to open() each ancestor directory to resolve the path — a file-read-data op on each — which the allow-list denies → EPERM. It's the exact (literal "/") situation one level down: the components between / and the workspace are traversable (metadata is global) but not openable, and realpath(3) needs the open.

Empirically (inside the cage): realpath(".") → EPERM, while fcntl(F_GETPATH), getattrlist(ATTR_CMN_FULLPATH), getcwd, and a userspace lstat-walk all succeed (they don't open ancestors). That's why bun --version/bun pm ls/Bun.spawnSync work but bun run/bun x don't, and why bun x from /tmp works (/private, / are broadly readable).

Fix

Grant (allow file-read* (literal "<dir>")) on each strict ancestor of the workspace root (and each composition member), up to but not including /. Using literal (the directory node only, not subpath) lets realpath/traversal open the path components without exposing sibling subtrees' contents — the same trade-off as the existing (literal "/") grant, one level down. Sibling names are already enumerable via the global metadata allow, so this leaks no new secrets (sibling CONTENTS stay denied by (deny default)).

A shared helper, workspace_ancestor_dirs, is used by both render_profile (enforcement) and compute_monitor_policy (the would-block classifier) so the two stay in sync — MonitorPolicy gains a read_literals set checked with exact-match (not the subtree under() check) so monitoring mode doesn't mis-classify these ancestor reads.

Testing

• cargo test --lib sandbox:: → 55 pass (52 existing + 3 new):
  • ancestor_dirs_walks_up_to_but_not_root
  • workspace_ancestor_dirs_strict_ancestors_only
  • would_block_allows_ancestor_node_read_not_subtree
• cargo check clean; cargo clippy --lib introduces no new warnings (the pre-existing ones are untouched).
• The existing would_block_classifies_pure_allowlist test was updated for the new read_literals field (set to vec![], behavior unchanged).

I verified the root cause end-to-end on a live enforcing workspace (the realpath EPERM repro in #35) and confirmed the fix follows the existing (literal "/") pattern, but I could not run a full signed app build in my environment — CI / a maintainer build is the final confirmation that a real sandboxed bun run now succeeds.

---

By opening this PR I agree to the CLA per CONTRIBUTING.md.

[simion]

Thanks for contributing!

tested locally and it works accordingly. 🍻