feat(cli): enforce /add-dir via sandbox writable roots — in every host

[oratis]

Reworks #166. Same core idea, but that PR is now both incomplete and carries stale docs — details below.

The gap

permissions.additionalDirectories is declared in the settings schema and read by /permissions for display, but consumed for enforcement nowhere. /add-dir printed:

Recorded /some/path as additional allowed directory (effective in M3).

M3 shipped. Nothing ever started reading it. A user running /add-dir would reasonably believe it took effect.

Why the sandbox is the right boundary

The file tools (Read/Write/Edit/Glob/Grep) already accept any absolute path — there is no cwd containment to widen, so there's nothing for /add-dir to "unlock" there. The only thing that actually restricts writes is the OS sandbox wrapping Bash. So enforcing /add-dir means folding those directories into filesystem.allowWrite.

That's #166's insight and it's correct.

What #166 could not have covered

#166 was written before the app-server existed, and wires only the CLI REPL and headless paths. Since #192/#195/#196, desktop, VS Code, and LSP all run through apps/server. Merging #166 as-is would enforce the setting in the CLI and silently ignore it in every other client.

For a security-relevant setting that's worse than not shipping it, because the two states are indistinguishable from the UI — /add-dir reports success either way.

All 7 sandbox assembly sites across 4 files now route through one helper:

file	sites
apps/cli/src/repl.ts	2 (RuntimeHost + plugin capability bridge)
apps/cli/src/headless.ts	2 (same pair)
apps/server/src/default-runtime.ts	1 (RuntimeHost — backs desktop/VS Code/LSP)
apps/server/src/runtime-composition.ts	2 (plugin capability bridge + plugin wire)

The plugin-bridge sites matter as much as the RuntimeHost ones: a plugin's bash capability goes through the same sandbox, so missing those would leave plugin-issued writes on the old, narrower root set.

The helper

withAdditionalWritableDirs(sandbox, dirs, cwd?) in core — pure, and deliberately conservative:

• Never mutates its input.
• No-op when the sandbox is disabled. It must never enable a sandbox as a side effect of adding a directory, and it must never appear to grant access that isn't actually mediated.
• Dedupes against existing allowWrite entries, and returns the original object unchanged when nothing new is added.
• Drops non-absolute entries rather than passing them down. The sandbox profile writers require absolute paths; a bare relative string would be meaningless or, worse, mis-anchored by the time it reached the profile.

/add-dir itself

Validates the path is an existing directory (a file is rejected explicitly), stores it absolute (resolved against cwd — a relative entry would re-anchor to whatever cwd a later session happened to start in), refuses duplicates, and lists the current set when called with no args.

Docs

Only the /add-dir row of BEHAVIOR_PARITY.md changes. #166 rewrote the entire table with June-era content that would have regressed /btw, /voice, /tasks and /background back to unshipped — all four have since landed in #168, #175 and #172. Prettier reflows the table columns on any edit, so git diff -w is the useful view: 2 real lines.

Verification

• tsc -b --force, pnpm lint (--max-warnings=0), pnpm format:check, pnpm docs:check — clean
• pnpm test — 1048 pass, including 9 new helper tests and 6 new /add-dir tests
• pnpm build — clean

The helper tests pin the properties that make this safe rather than just the happy path: no-mutation, disabled-sandbox no-op, dedupe identity, and relative-entry dropping.

Closes #166.

🤖 Generated with Claude Code