toolroll 0.9.68 → 0.9.70

package/CHANGELOG.md

@@ -1,5 +1,86 @@
 # Changelog
 
+## 0.9.70 — 2026-10-24
+
+- **Every sandbox is now Anthropic's sandbox-runtime.** Builds, their setup
+  and check commands, a saved result's checks, flows and project tool servers
+  all run in `@anthropic-ai/sandbox-runtime` 0.0.79, the same sandbox Claude
+  Code uses: its own code writes the macOS Seatbelt profile and the Linux
+  bubblewrap and seccomp command for each launch. Toolroll hands it only a
+  short list: its own folders and database are off limits, the build's
+  checkout is writable, other tasks' checkouts are read and never written,
+  your project's read-deny list, and the run's proxy as the only way out.
+  `toolroll doctor` and Settings → Project → Home folder name the engine and
+  its version. Codex builds keep Codex's own sandbox with the same rules.
+- **Checks that start Chrome don't run sandboxed on macOS yet.** The sandbox
+  runtime has no setting for the service Chromium registers at startup, so a
+  Playwright or browser check fails inside it. Until a follow-up adds that one
+  rule, set such a project's check access to **Not sandboxed** in
+  Settings → Project → Check access.
+- **Your home folder is readable to new scopes, as in the sandbox runtime.**
+  A project hides what it wants back with Settings → Project → **Home
+  folder**, or `toolroll project sandbox --repo <p> --read-deny "~/.ssh"`.
+  Each approved scope seals its list. Scopes approved before 0.9.70 keep
+  hiding your credentials and agent settings, as they were approved.
+- **The macOS services a project's builds may also reach** (`--mach`, for Go
+  tools that verify TLS through trustd) seal only on a person's password.
+  Approval cards and the CLI's scope view say what a scope reads and which
+  services it adds.
+- **Checks can use your Claude, Codex and GitHub sign-ins again.** The
+  "Sandboxed, with model and GitHub sign-ins" level is on: a check reads
+  exactly those files, by name, inside its sandbox, never through a link.
+- Flows, tool servers started outside a build and interactive Codex coding
+  sessions now run in the same sandbox as builds. A machine that can't
+  sandbox runs none of them unless an instance operator allowed unconfined
+  agents.
+- On Linux the sandbox needs bubblewrap, socat and ripgrep; without them
+  nothing starts (as before, unless unconfined agents are allowed).
+- A result that adds or changes a Git hook or config, editor or Claude
+  settings, a shell profile, `.envrc`, `.npmrc` or `.mcp.json` is refused at
+  the handoff, with its work kept. Toolroll's own install and the sandbox
+  runtime can't be written from inside a sandbox.
+- The scout's browser runs outside the sandbox, as an explicit exception: a
+  pinned Playwright release installed from a lockfile into Toolroll's own
+  folder, with exactly the arguments and environment it was approved with.
+- Limits that come with the sandbox runtime: rules are fixed when a launch
+  starts, concurrent builds share its temp folder, and on macOS a build can
+  read another process's arguments and environment. Write unlocks for
+  protected files are gone (the runtime can't grant them).
+
+## 0.9.69 — 2026-10-23
+
+- **Choose how far a project's checks reach.** Settings → Project has a new
+  Check access section, and `toolroll project check-access --repo <p>` shows
+  or sets the same thing. **Sandboxed** (the default) runs a project's setup
+  and check commands in the plane's fence, as before. **Not sandboxed** runs
+  them with your full access, as before 0.9.66: for a project whose checks
+  must create sandboxes themselves, such as Toolroll's own.
+- Widening takes an instance operator with their password typed now (a
+  remembered sign-in or a single sign-on recheck doesn't count). Any approver
+  for the project can narrow it back. Each change is in the ledger.
+- The level is part of what you approve. A scope seals it, the approval card
+  says "Checks: not sandboxed", and tasks already approved keep the level
+  they were approved with. Each run records the level its checks actually ran
+  at, and the result page says when they ran without a sandbox. Later checks
+  of a saved result never run wider than that run did. A mode, a grant or a
+  chat confirmation can't approve a wider level; only a person's password can.
+- **A third level, "Sandboxed, with model and GitHub sign-ins", is built but
+  off.** It would let a check read your Claude, Codex and GitHub sign-in files.
+  Reading those files safely needs a way to open a file that a running build
+  can't redirect partway (Node can't do that yet), so the option is shown
+  disabled with the reason. Choosing it is refused, and a level saved before
+  runs sandboxed and says so.
+- **The fence holds your home configuration by name.** `~/.codex`,
+  `~/.config/gh`, `~/.ssh` and the rest are denied whether or not they exist
+  when a build starts, so a build can't create one or swap it for a link
+  later. The folders above them can't be renamed or made during a build.
+- A check's temporary folder on a Mac is now short (under `/private/tmp`), so
+  tests that open a unix socket there work inside the fence. Other launches'
+  folders stay out of reach.
+- With no OS sandbox on the machine and unconfined running allowed, the
+  settings page and `project check-access` say checks run without a sandbox,
+  whatever level is saved.
+
 ## 0.9.68 — 2026-10-23
 
 - **The lead chat is redesigned.** Your messages sit in grey bubbles and the

package/README.md

@@ -565,24 +565,47 @@ Use Full access only for repositories and setup commands you trust.
 
 ### What an agent can reach
 
-Agents run as your own user, so Toolroll fences its own secrets off
-from them at the operating system, in every permission mode. The fence covers
-the state folder beside the database (your remembered login `up-login.txt`,
-runner and coordinator tokens, chat bot tokens, the database and its backups,
-other runs' evidence) — everything there except the build's own worktree —
-and `~/.toolroll` (stored provider keys and project tool secrets).
-
-Seatbelt and bubblewrap deny the whole checkout pool and allow the build’s own
-checkout back, covering other projects created after launch too. Codex keeps
-the own checkout’s ancestors traversable and denies each other project folder
-found in trusted checkout pools at launch. A project added after a Codex build
-starts is covered on the next launch. Own Git data, linked shared dependencies
-and launch tools remain available.
+#### Sandboxing: built on Anthropic's sandbox-runtime (v0.0.79)
+
+Every fenced launch (a build's agent, its setup and check commands, a saved
+result's checks, a flow's setup and script, a project tool's server) runs inside
+[Anthropic's sandbox-runtime](https://github.com/anthropics/sandbox-runtime)
+(`@anthropic-ai/sandbox-runtime`, pinned to 0.0.79): the same sandbox Claude Code
+uses. Its own code writes the macOS Seatbelt profile and the Linux bubblewrap and
+seccomp command for each launch, with its baseline, its protected names and its
+limits; Toolroll only hands it a short config. `toolroll doctor` and Settings →
+Project → **Home folder** name the engine and its version. Where it can't run
+(Windows; Linux without bubblewrap, socat or ripgrep, or with unprivileged user
+namespaces off), nothing starts unless an instance operator allows unconfined
+agents (`toolroll config unconfined-agents allow`). Codex builds use Codex's own
+sandbox, given the same rules.
+
+What Toolroll adds to the runtime's config, and nothing else:
+
+- **Toolroll's own folders** are denied to read and write: the state folder
+  beside the database (your remembered login `up-login.txt`, runner and
+  coordinator tokens, chat bot tokens, the database and its backups, other runs'
+  evidence) except the checkout pool, and `~/.toolroll` (stored provider keys and
+  project tool secrets); other launches' private folders are unread.
+- **The build's own checkout** is writable; **other tasks' checkouts** are read,
+  never written (those there when it starts).
+- **Your home folder** is readable, as in the runtime (a scope approved before
+  0.9.70 keeps hiding your credentials and agent settings, as it was approved). A
+  project hides more with Settings → Project → **Home folder**, or `toolroll
+  project sandbox --repo <p> --read-deny "~/.ssh,~/.aws"`; each approved scope
+  seals that list.
+- **The network**: open, or only through the run's own proxy (below).
+
+The runtime's limits are accepted as they are: rules are fixed when a launch
+starts; on Linux a deny for a path that isn't there yet is the runtime's to handle;
+concurrent builds share the system temp folder; another process's arguments and
+environment can be read on macOS; and a folder or checkout made after a build
+starts is writable to it unless something above denies it.
 
 | | Auto | Full access |
 |---|---|---|
-| **Codex / OpenRouter** (any OS) | Codex's sandbox with the fence: writes only the checkout, its Git data and the project's caches (anywhere outside the fence, under a project set to write anywhere); no network | the same writes, with the fence; its commands reach the network only when the project's network is open |
-| **Claude, Gemini, ACP agents** | macOS: inside a Seatbelt sandbox that denies the fence and writes only the checkout, its Git data, the project's caches, the run's temp folder and the agent's own session files. Linux: the same in bubblewrap, with a /tmp of its own. Neither (Windows, or Linux without bubblewrap): the build doesn't start, unless an instance operator allows unconfined agents | same |
+| **Claude, Gemini, ACP agents** | Anthropic's sandbox-runtime (Seatbelt on macOS; bubblewrap and its seccomp filter on Linux, which also needs socat and ripgrep): reads your home folder except the folders the project lists, never Toolroll's folders; other tasks' work read, never written; writes only the checkout, its Git data, the project's caches, the run's temp folder and the agent's own session files (anywhere outside the fence, under a project set to write anywhere), never the runtime's protected names in the checkout (Git hooks and config, shell profiles, `.mcp.json`, editor settings); no Apple Events. Neither (Windows, or a Linux missing one of those): the build doesn't start, unless an instance operator allows unconfined agents | same |
+| **Codex / OpenRouter** (any OS) | Codex's own sandbox, given the same fence: reads your home folder except the folders the project lists, never Toolroll's folders; other tasks' work read, never written; writes only the checkout, its Git data and the project's caches (anywhere outside the fence, under a project set to write anywhere); no network | the same reads and writes, with the fence; its commands reach the network only when the project's network is open |
 
 **Where a build writes.** Each approved scope also seals where its build may
 write. By default (Settings → Project → **Where builds write**, or `toolroll
@@ -618,8 +641,9 @@ mode** an agent's own provider key is in its environment, so its shell can
 read it (subscription mode, the default, puts no key there); and a project's
 own tool secrets reach that project's tools. They stay in a per-run broker
 outside the fence: the agent gets only its address and a token that stops
-working when the run ends, and on macOS it can't read another process's
-arguments or environment. Reviews and the lead chat run with no tools and are
+working when the run ends. A tool server's own environment (its secrets among it)
+is readable to a build on macOS through the process list, a limit of the sandbox
+runtime's baseline. Reviews and the lead chat run with no tools and are
 confined to their own files. See [SECURITY.md](SECURITY.md).
 
 ### How build sessions are protected
@@ -1198,6 +1222,8 @@ about seven minutes, and writes `report.md`, screenshots and both logs to
 
 ## Credits
 
+Every sandbox Toolroll runs is [Anthropic's sandbox-runtime](https://github.com/anthropics/sandbox-runtime) (Apache-2.0), used as a dependency; see THIRD_PARTY_NOTICES.md.
+
 The workflow this formalizes comes from [Jason Ku's agentic engineering session](https://youtu.be/Ukju3maxbEQ) and his [`agents-md-snippets`](https://github.com/jasonku09/agents-md-snippets), plus Kun Chen's `treehouse`, `no-mistakes`, `gnhf`, `tasks-axi`, and `axi`. The design was reviewed adversarially by Codex; the appendix in `docs/DESIGN.md` lists every claim that review falsified, because the corrections are more useful than a clean spec would have been.
 
 ## License

package/THIRD_PARTY_NOTICES.md

@@ -487,4 +487,24 @@ COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
 DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
-OTHER DEALINGS IN THE FONT SOFTWARE.
+OTHER DEALINGS IN THE FONT SOFTWARE.
+
+## Anthropic sandbox-runtime — Apache-2.0
+
+Copyright Anthropic PBC. https://github.com/anthropics/sandbox-runtime
+
+`@anthropic-ai/sandbox-runtime` 0.0.79 is a dependency, installed whole from npm with its own `LICENSE` (and its
+prebuilt Linux seccomp helpers, `vendor/seccomp/<arch>/apply-seccomp`). Toolroll calls it for every sandbox it runs
+(`src/sandbox-runtime.ts`, `src/sandbox-launch.ts`) and copies or modifies none of its code.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

package/dist/agent-fence.d.ts

@@ -1,6 +1,6 @@
 import type { LoopbackMode } from "./egress.js";
-/** Beside the database: where Linux builds' network bridges are made (its name reads as secret wherever it is). */
-export declare const BRIDGE_DIR = "bridge-secrets";
+import type { ExecutionProfile } from "./scope.js";
+import { type SrtTerms } from "./sandbox-runtime.js";
 /** How a launch was fenced, as recorded on the run and said on the task. */
 export type FenceMethod = "codex-profile" | "macos-sandbox" | "linux-bubblewrap" | "claude-rules" | "none";
 /** Only the plane's recorded repository may supply an own-Git exemption. */
@@ -38,6 +38,9 @@ export type TaskBoundary = {
     fileTools: string[];
     readOnly: string[];
     lookup: string[];
+    /** Every home configuration name the launch may not reach, by name, whether or not it exists now (macOS: Seatbelt
+     * denies a path that isn't there yet, so a build can't create it, or later replace it with a link). */
+    homeNames?: string[];
 };
 /**
  * Everything outside a task's own folders that a build could otherwise
@@ -52,26 +55,30 @@ export declare function taskBoundary(options: {
     provider: string;
     home?: string;
     binding?: WorktreeBinding | null;
+    policy?: FencePolicy;
 }): TaskBoundary;
-/** Where launches keep their private folders (the system temp folder), and this launch's own tool folder. */
+/** Where launches keep their private folders: `root` (the system temp folder) and, on a Mac, `also` the short shared one
+ * a check's launch folder is made in (/private/tmp, so its unix sockets fit); `own` is this launch's. */
 export type RunFolders = {
     root: string;
     own: string | null;
+    also?: string[];
 };
-/** The prefixes of every launch's private folders: its tools' config, a Codex build's own home, and a Linux build's
- * network bridge (egress-bridge.ts). */
+/** The prefixes of every launch's private folders: its tools' config and a Codex build's own home (and a check's). */
 export declare const RUN_FOLDER_PREFIXES: readonly ["so-tools-", "so-codex-", "so-net-", "so-cmd-"];
 export declare function runFolders(own: string | null, root?: string): RunFolders;
+/** Where a check's launch folder is made on a Mac: a short shared folder, so its TMPDIR leaves room for a unix socket
+ * path (about 104 bytes). */
+export declare const CHECK_LAUNCH_ROOT_MACOS = "/private/tmp";
+/** The folder a check's launch folder is made in: on a Mac the short one, elsewhere the system temp folder. */
+export declare const checkLaunchRoot: () => string;
+/** Every root launch folders are made under (the system temp folder, and on a Mac the short shared one). */
+export declare const runRoots: (folders: RunFolders) => string[];
 /**
- * What a fence gives back beside its denied paths. Each is narrow and none
- * ever writes: `readOnly` is read, never written (other tasks' git
- * metadata); `readable` is read and run inside a denied folder (the shared
- * dependencies this checkout links); `lookup` is only looked up, never
- * listed or read (the deps root and the copy linked, other tasks' checkout
- * roots); `runFolders` denies every launch folder in the temp folder but
- * this launch's own (macOS: by pattern, so a later one is denied too);
- * `pool` denies the plane's checkout pools whole and gives this build's own
- * checkout back (CheckoutPool).
+ * What a fence gives back beside its denied paths. `readOnly` is read, never written (other tasks' git metadata, the
+ * primary checkout under v2); `readable` is read inside a denied folder (the shared dependencies this checkout links);
+ * `lookup` is kept for Codex (looked up, never listed); `runFolders` names this launch's own private folder and where
+ * the others are; `pool` denies the plane's checkout pools around this build's own checkout (CheckoutPool).
  */
 export type FenceGrants = {
     readOnly: string[];
@@ -81,6 +88,14 @@ export type FenceGrants = {
     pool?: CheckoutPool;
     network?: NetworkFence;
     writes?: WriteAllowlist;
+    /** Policy v1: the home configuration names denied by name, present or not (TaskBoundary.homeNames). */
+    homeNames?: string[];
+    /** macOS: the project's sealed mach services beyond the runtime's baseline (its `allowMachLookup`). */
+    machLookup?: string[];
+    /** A `sign-ins` check's exact sign-in files, read again inside the home denies (check-access.ts, signInGrants). */
+    signIns?: SignInGrants;
+    /** Never written, wherever the launch writes (homeWriteDenies): what runs for the operator next or signs them in. */
+    writeDenies?: string[];
 };
 export { isWritesMode, WRITES_DEFAULT, type WritesMode } from "./writes-mode.js";
 /**
@@ -136,13 +151,10 @@ export declare function buildCacheFolder(repo: string, home?: string, platform?:
 /** The environment that points a build's package managers at its project's cache folder, not the user's own. */
 export declare function buildCacheEnv(folder: string): Record<string, string>;
 /**
- * A launch's network confinement (egress.ts, docs/plans/agent-baseline-hardening.md arc 1). `open`: the network as it
- * always was. `allowlist`: nothing leaves the machine but through the run's own proxy (`proxyPort`); the run's tool
- * broker (`brokerPorts`) stays reachable; on macOS this Mac's other local services are reachable only under
- * `loopback: "any"` (all of them: Seatbelt can't refuse one local port once it admits the rest); unix sockets only
- * under `socketRoots` (the run's own temp folder and checkout). On Linux the agent gets a network of its own and
- * reaches the proxy and broker through `bridge` (a folder of unix sockets the plane serves, and the forwarder that
- * carries them onto the namespace's own loopback).
+ * A launch's network confinement (egress.ts). `open`: the network as it always was. `allowlist`: nothing leaves the
+ * machine but through the run's own proxy (`proxyPort`, which admits only this run's `token`); the run's tool broker
+ * (`brokerPorts`, at most one) rides the sandbox runtime's second relay; this machine's other local services are
+ * reachable only under `loopback: "any"`; unix sockets only under `socketRoots` (macOS).
  */
 export type NetworkFence = {
     mode: "open";
@@ -152,21 +164,8 @@ export type NetworkFence = {
     brokerPorts: number[];
     loopback: LoopbackMode;
     socketRoots: string[];
-    bridge?: {
-        folder: string;
-        forwarder: string;
-        node: string;
-    };
-    /** Linux: the run's own folders a private /tmp gives back (its checkout, its launch folder), when they are there. */
-    keep?: string[];
+    token?: string;
 };
-/**
- * Services a sandboxed process could ask to act outside the sandbox for it (macOS): open a URL in a browser (Launch
- * Services), script another application (Apple Events), fetch in the background (nsurlsessiond), look a name up
- * (the DNS service: a lookup is itself a message out), or read and write the clipboard. Denied when the network is
- * confined; the run's proxy resolves names for it.
- */
-export declare const DELEGATION_SERVICES: readonly string[];
 export declare const NO_GRANTS: FenceGrants;
 /**
  * The plane's checkout pools, denied whole: every project's worktrees, and any made there after launch. `agentFence`
@@ -178,6 +177,11 @@ export type CheckoutPool = {
     own: string | null;
     lookup: string[];
     gitPaths?: string[];
+    /** Policy v2 (owner Q-C): other tasks' checkouts are read, never written (agents can work together); v1 denies both. */
+    readable?: true;
+    /** Folders inside the pool that stay denied whole whatever the policy (flows' scratch folders hold their inputs and
+     * outputs), this launch's own folder given back. */
+    sealed?: string[];
 };
 /**
  * The pool deny for one launch. `roots` come from the plane's own records (the pool beside the database, and the one
@@ -224,6 +228,13 @@ export declare function fencedGitEnv(base?: Readonly<Record<string, string | und
  * `codexPool`, which denies them around the build's own checkout, written back.
  */
 export declare function codexFenceArgv(fence: readonly string[], fullAccess: boolean, grants?: FenceGrants): string[];
+/**
+ * The same permission profile as codexFenceArgv, as the config overrides a Codex app-server thread takes
+ * (`thread/start` and `thread/resume` `config`; checked against codex-cli 0.156: the thread reports
+ * `activePermissionProfile` standing-orders, and its commands are refused the denied paths). Approval policy is the
+ * caller's own (an interactive session asks).
+ */
+export declare function codexFenceConfig(fence: readonly string[], fullAccess: boolean, grants?: FenceGrants): Record<string, unknown>;
 /**
  * Codex cannot deny an ancestor and still traverse it to the own checkout. Deny existing
  * siblings individually, from the trusted pool roots and a fresh listing, never through
@@ -256,39 +267,6 @@ export declare function flattened(fence: readonly string[], grants?: FenceGrants
 /** Claude's own file tools refuse the fenced paths in every mode (its shell is fenced by the macOS sandbox), and
  * never edit a read-only one. */
 export declare function claudeFenceSettings(fence: readonly string[], readOnly?: readonly string[]): string;
-/**
- * The folders the user owns above each path (never `/`, nor the path itself), and each `roots` folder itself when the
- * user owns it. A Seatbelt path rule follows the name, not the folder: renaming one of these would bring a fenced path
- * back under a name no rule mentions. A folder the user doesn't own can't be renamed by a build anyway.
- */
-export declare function ownedAncestors(paths: readonly string[], roots?: readonly string[], uid?: number | undefined): string[];
-/**
- * A Seatbelt profile that allows everything except reading or writing the
- * fenced paths, less what `grants` gives back (a later Seatbelt rule
- * outranks an earlier one). Whatever the paths, the process can't read
- * another's arguments and environment (`kern.procargs`, which `ps -E` and
- * KERN_PROCARGS2 use) or inspect a process outside its own sandbox:
- * `process-info*` limited by target alone doesn't stop the sysctl. It can't
- * take another process's task port either (`task_for_pid`, what lldb attaches
- * with; a task name port too), so a tool server's or Toolroll's own memory
- * and environment stay out of reach. Last, every folder of the user's above
- * a fenced or read-only path and above the temp folder (and the temp folder
- * itself) can't be renamed or removed, though what is inside them stays
- * writable as before. The checkout pools are denied first, and the build's own
- * checkout given back right after, so every later deny still holds inside it.
- */
-export declare function macosFenceProfile(fence: readonly string[], grants?: FenceGrants): string;
-/**
- * The network half of the macOS fence. Every outbound connection is denied, then loopback is given back as the launch
- * allows: every local port under `loopback: "any"`, else the run's proxy and broker alone. (Seatbelt admits a port an
- * allow names whatever a deny after it says, so a local port can't be refused once all are admitted: the choice is all
- * or none, plus the run's own.) Filters name the remote end only: a `local ip` filter would admit any outbound
- * connection.
- */
-export declare function macosNetworkRules(network: NetworkFence | undefined): string[];
-export declare const SANDBOX_EXEC = "/usr/bin/sandbox-exec";
-/** Where macOS's resolver (mDNSResponder) answers: every name lookup on a Mac is a message to this socket. */
-export declare const MACOS_DNS_SOCKET = "/private/var/run/mDNSResponder";
 /**
  * Whether this machine can run an agent inside the macOS fence (checked once). Not from inside another
  * sandbox: a Toolroll a fenced process starts (the end-to-end journeys a flow's check zone runs) can't nest
@@ -300,23 +278,24 @@ export declare function macosFenceAvailable(platform?: NodeJS.Platform, probe?:
     status: number | null;
     stderr: string;
 }): boolean;
-/** The spawn that runs `file args` inside the macOS fence (same process: sandbox-exec replaces itself with the agent). */
-export declare function macosFenced(file: string, args: readonly string[], fence: readonly string[], grants?: FenceGrants): {
-    file: string;
-    args: string[];
-};
 export declare function linuxFenceAvailable(platform?: NodeJS.Platform, probe?: () => boolean): boolean;
-/** The spawn that runs `file args` inside the Linux fence: the whole filesystem as it is, the checkout pools masked
- * and the build's own checkout bound back read-write over them, then every fenced path masked whole (an empty
- * folder, or /dev/null for a file), so what is made there after launch is masked too; then only the explicit grants
- * bound back read-only (bubblewrap binds from the original root, so a grant inside a mask still reaches its files). */
-export declare function linuxFenced(file: string, args: readonly string[], fence: readonly string[], grants?: FenceGrants): {
+/** Thrown when no sandbox can be made for a launch: the spawn road refuses it. */
+export declare class LinuxFenceUnavailable extends Error {
+}
+/**
+ * The runtime's config for a launch (sandbox-runtime.ts SrtTerms), from its fence: every fenced path denied to read and
+ * write (with the exact paths read again inside them), the pools' other checkouts write-denied (and, under v1, read-
+ * denied) around the build's own, the flows' scratch folders sealed, the launch's writes (its allowlist, or anywhere
+ * outside the denies), its mach services and its network.
+ */
+export declare function srtTermsOf(fence: readonly string[], grants?: FenceGrants): SrtTerms;
+/** The spawn that runs `file args` from `cwd` inside the sandbox runtime's sandbox (sandbox-runtime.ts srtSpawn), and the
+ * environment it needs beside the caller's. */
+export declare function sandboxedSpawn(file: string, args: readonly string[], fence: readonly string[], grants?: FenceGrants, cwd?: string, temp?: string): {
     file: string;
     args: string[];
+    env: Record<string, string>;
 };
-/** The host's own sockets a process in a mounted filesystem could still talk to (D-Bus, the display, container
- * engines), wherever they exist here. */
-export declare function linuxHostSockets(uid?: number | undefined, home?: string, tmp?: string, followLinks?: boolean, env?: Readonly<Record<string, string | undefined>>): string[];
 /**
  * What each agent's fence gives it, by permission mode: the one table README's "What an agent can reach" shows
  * (fenceSummaryMarkdown; a test holds them equal).
@@ -328,3 +307,147 @@ export declare const FENCE_SUMMARY: readonly {
 }[];
 /** FENCE_SUMMARY as README's markdown table. */
 export declare function fenceSummaryMarkdown(): string;
+/** What a `sign-ins` check reads and writes beyond its fence (check-access.ts): its exact sign-in files, its own Claude
+ * transcript folder (macOS) and Codex's session and log folders. */
+export type SignInGrants = {
+    read: string[];
+    transcripts: string[];
+    writes: string[];
+    /** macOS services the sign-ins need: certificate checking (trustd), without which gh (Go) can't verify GitHub's TLS
+     * and calls its own token invalid. Measured with gh 2.x on macOS 26. */
+    mach: string[];
+};
+/**
+ * A `sign-ins` check's grants (sandbox parity C10, srt-style): each sign-in file by its name, read by the check itself
+ * through its sandbox. Nothing privileged reads or copies one: the sandbox resolves the name in its own view, so a link
+ * planted there into Toolroll's state leads to a denied path (Seatbelt checks the resolved file; bubblewrap resolves
+ * inside its mount namespace, where the state is masked). On a Mac, the checkout's own Claude transcript folder (made
+ * when absent, only as the real folder it is), whose session files alone are written; and Codex's session and log
+ * folders (when ~/.codex is there), never its config.
+ */
+export declare function signInGrants(home: string, checkout: string, platform?: NodeJS.Platform): SignInGrants;
+/** Whether a sign-in file is itself, now: every folder from the (real) home folder down a real folder, the file a
+ * regular file with one name (never a link, never a hard link to something else). Checked when granted and again right
+ * before the launch (invoke.ts); the sandbox resolves the name a third time. */
+export declare function signInIsItself(base: string, path: string): boolean;
+/**
+ * Which fence policy a launch runs under (docs/plans/sandbox-parity.md §1.5). v1: the fence as approvals sealed before
+ * 0.9.70 knew it (the home configuration, the repositories beside the project and its primary checkout denied to read).
+ * v2: those reads open, as in Anthropic's sandbox runtime, less what the project's sealed `readDeny` names. A widening,
+ * so only a scope sealed at v2 runs under it; every narrowing applies to both.
+ */
+export type FencePolicy = 1 | 2;
+export declare const FENCE_POLICY_CURRENT: FencePolicy;
+/** Who a launch is (docs/plans/sandbox-parity.md §3): a build's agent, its setup and check commands, a saved result's
+ * checks, a flow's setup, script or trigger, or a tool server. Each gets its fence from `fenceFor`, and only from it. */
+export type FenceKind = "build" | "command" | "check" | "flow" | "tool-server";
+/**
+ * What `fenceFor` needs. The boundary and the trusted binding are required, as values or an explicit null (a launch
+ * with no checkout), so no caller forgets one; every path comes from Toolroll's own records, never from the checkout.
+ */
+export type FenceContext = {
+    databaseFile: string | null;
+    worktree: string | null;
+    boundary: TaskBoundary | null;
+    binding: WorktreeBinding | null;
+    runFolders: RunFolders;
+    /** The checkout pools, from the plane's records (CheckoutPool). */
+    poolRoots: readonly (string | null)[];
+    home?: string;
+    /** Denied beside the fence (a provider's live session keys, say). */
+    extra?: readonly string[];
+    /** The shared dependencies this checkout links, as the plane recorded them. */
+    linked?: {
+        repo: string;
+        setupDigest: string | null;
+    } | null;
+    /** A workspace launch's write allowlist and what it adds read-only (writeAllowlist); absent: writes anywhere its
+     * fence allows. */
+    writes?: {
+        writes: WriteAllowlist;
+        readOnly: string[];
+    } | null;
+    /** The launch's network, when it has one of its own (a flow's: decided by its caller, never left unsaid). */
+    network?: NetworkFence;
+    /** What it may not read beside the fence, as absolute paths (project-sandbox.ts readDenyPath): denied whole. */
+    readDeny?: readonly string[];
+    /** macOS services it may also reach (project-sandbox.ts). */
+    machLookup?: readonly string[];
+    /** The fence policy it runs under: v2 reads other tasks' checkouts (never writes them). */
+    policy?: FencePolicy;
+    /** The agent the launch runs, whose own sign-in files stay its to write (PROVIDER_HOME). */
+    provider?: string;
+    /** Scratch folders (a flow's) that stay denied whole inside the pool, whatever the policy. */
+    scratchRoots?: readonly string[];
+};
+/** A launch's sealed sandbox terms (builder.ts launchSandboxOf): its policy version, read denies and mach services. A
+ * launch with none sealed is v1 with none of them. */
+export type LaunchSandbox = {
+    policy: FencePolicy;
+    readDeny: readonly string[];
+    machLookup: readonly string[];
+};
+export declare const LEGACY_SANDBOX: LaunchSandbox;
+/** A build's sandbox terms, exactly as its approval sealed them: an approval from before 0.9.70 is policy v1 (the home
+ * configuration denied) with nothing listed. */
+export declare function launchSandboxOf(profile: ExecutionProfile): LaunchSandbox;
+/** A launch's whole fence: its denied paths, what it gives back, and that it runs inside the OS fence or not at all.
+ * Spread into RunOptions as is. */
+export type LaunchFence = {
+    kind: FenceKind;
+    fence: string[];
+    fenceGrants: FenceGrants;
+    confinement: "required";
+};
+/** The one place a launch's fence is made (docs/plans/sandbox-parity.md C1): its denies, its grants, and
+ * `confinement: "required"`, so the spawn road refuses it where no OS fence applies rather than running it bare. */
+export declare function fenceFor(kind: FenceKind, ctx: FenceContext): LaunchFence;
+/** The flows' scratch folders inside the checkout pools (`flow-checks` beside the checkouts) and any a caller names,
+ * each denied by name whether or not it is there yet, and where it is a link, where it leads too. */
+export declare function sealedScratch(poolRoots: readonly (string | null)[], named: readonly string[]): string[];
+/**
+ * Toolroll's own install as no launch may write it: this package's folder (its compiled code, the sandbox launch
+ * helper among it), the sandbox runtime's package wherever it was installed, and the Node running them with the
+ * folder it lives in (its npm and global packages beside it), as the real folders they are. Never a folder that holds
+ * the launch's own checkout or its repository (a build of Toolroll's own source, run from it: that repository's other
+ * files are the primary checkout's, write-denied already), the home folder or one above it, and nothing the user
+ * doesn't own (root's folders are out of a build's reach already).
+ */
+export declare function toolrollInstall(worktree: string | null, home: string, repository?: string | null): string[];
+/** Names that run code or reconfigure tools for whoever opens the project next: the sandbox runtime's DANGEROUS_FILES
+ * (@anthropic-ai/sandbox-runtime sandbox-utils), and the names its mandatory denies can't hold when they are made
+ * after a launch starts (`.envrc`, package-manager and Claude settings). */
+export declare const PROTECTED_FILES: readonly string[];
+/** Folders protected whole, wherever they are (the runtime's dangerous directories, with Git's hooks). */
+export declare const PROTECTED_DIRS: readonly string[];
+/**
+ * The handoff's backstop (builder.ts commit): the changed paths (relative, from Git) that are protected names at any
+ * depth, in any case. The sandbox runtime denies these when a launch starts; one made after it started (a new nested
+ * folder's `.envrc`, say) gets through the sandbox, and a result that holds it is refused.
+ */
+export declare function protectedChanges(changed: readonly string[]): string[];
+/**
+ * The handoff's backstop for links (builder.ts commit): a staged symbolic link (Git mode 120000) whose path is a
+ * protected name or a folder on the way to one (`pkg/.claude`, `.vscode`, `lib/.git`), at any depth, in any case. A
+ * link there would lead whoever opens the project to settings, hooks or commands kept anywhere.
+ */
+export declare function protectedLinks(links: readonly string[]): string[];
+/** The home folder's own persistence points beyond the protected names (login items, systemd user units and autostart,
+ * Git's, gh's, pip's and fish's configuration, the shells' other startup files, SSH and GnuPG, and the folders on a
+ * login PATH). Under `.config/` each also stands under $XDG_CONFIG_HOME. */
+export declare const HOME_PERSISTENCE: readonly string[];
+/**
+ * What no launch writes, whatever its writes, as static write denies for the sandbox runtime (whose own protected names
+ * are anchored at the launch's folder only) and Codex's profile: the home folder's protected names (shell profiles, Git
+ * and tool configuration), its persistence points and sign-ins (but the launch's own agent's exact sign-in files), and
+ * the bound repository's own Git config, hooks and submodules (a linked worktree reaches them through its `.git`
+ * file). Each by its name and by where it leads now (a linked ~/.config or LaunchAgents is denied at both ends). On
+ * Linux only those there at launch: the runtime holds an absent name with a stand-in nothing can read for the launch's
+ * length, and the person's own git and shells then fail on their ~/.gitconfig and ~/.bashrc (measured). Under a write
+ * allowlist an absent one is out of reach anyway; under `anywhere` it can be made (an accepted limit).
+ */
+export declare function homeWriteDenies(home: string, binding: WorktreeBinding | null, provider: string | null, platform?: NodeJS.Platform, env?: Readonly<Record<string, string | undefined>>): string[];
+/** A tool server's grants from its build's: never the agent's network or write allowlist (a server keeps its own state
+ * where it always has), and never the build's own checkout or launch folder read back (nothing a build wrote loads in a
+ * process that holds a tool's secrets). */
+export declare function serverGrantsOf(grants: FenceGrants): FenceGrants;