Two holes, one shape: a tool call could reach the filesystem or the shell
without the sandbox ever having an opinion about it.
`editPathOf` only read `file_path`, so `NotebookEdit` — which carries its target
in `notebook_path` — passed the confinement screen and the diff-capture hook
alike with an undefined path. Under `--safe` that meant a notebook edit anywhere
on disk. It reads both now, and `EDIT_TOOLS` keeps listing `MultiEdit` as
defence in depth even though claude no longer offers it.
`screenTool` replaces the per-call-site branching with one total, fail-open
dispatch from a tool name to `screenEdit` or `screenBash`. Fail-open is
deliberate: a read-only tool, an MCP tool, or a name this version has never
heard of is not the sandbox's business, and a screen that guessed would break
more than it protected. On allow it returns `{}` rather than a decision, so
`canUseTool` still runs behind it.
On the claude side `--safe` was asking for `permissionMode: "acceptEdits"`,
which pre-approves exactly the in-project edits `canUseTool` exists to inspect —
so the callback never ran for them. It is `"default"` now, and Bash goes through
the same `screenTool` rather than being waved through unscreened.
`allowDangerouslySkipPermissions` moves to the non-safe path, where skipping is
the point.
Separately the toolset stops being advisory. `allowedTools` only auto-approves;
it never removes anything, so the whole builtin set stayed reachable. `tools`
genuinely narrows it: `MultiEdit` and the MCP entry drop out, `BashOutput` and
`KillShell` come in because a backgrounded command is unreadable without them,
and `WebFetch`/`WebSearch` are excluded under `--safe`. That last one is why the
CLI banner changed — `--safe` disables the builtin web tools on both backends
now, not only on opencode.
Nayan
30ae4ae098