@snappedly-tools/shipyard 0.5.0-staging.36072068333 → 0.6.0

package/README.md

@@ -8,100 +8,201 @@
 
 [![CI](https://github.com/snappedly/shipyard/actions/workflows/ci.yml/badge.svg)](https://github.com/snappedly/shipyard/actions/workflows/ci.yml)
 
-Give Shipyard a task or a GitHub issue. It runs Codex or Claude Code in an
-isolated sandbox, can plan and review larger jobs, and brings the result back as
-a commit or pull request you can inspect.
+Give Shipyard a backlog and a policy. It plans dependencies, runs AI coding
+agents in isolated sandboxes, reviews their work, and returns reviewable
+commits—without babysitting.
 
 ## The Shipyard advantage
 
-- **Isolated work.** Docker keeps the agent's files and Git work inside a
-  sandbox while it runs.
-- **Built for real projects.** Shipyard can sort issue dependencies, work on
-  independent tasks in parallel, and review the combined result.
-- **You stay in control.** Runs have limits and logs. Issue workflows return a
-  pull request for you to review and merge.
+Most agent setups launch a CLI and hope for the best. Shipyard is the control
+plane around the agent:
 
-## Try it on one task
+- **Protected execution:** Run Codex or Claude Code in an isolated Docker-backed
+  sandbox with explicit mounts, credentials, and network access.
+- **Real orchestration:** Plan dependencies, parallelize safe work, leave
+  blocked work alone, review each branch, and merge completed work.
+- **Failure-aware by design:** Use finite budgets, no-progress detection,
+  cancellation, logs, and recovery artifacts instead of runaway loops.
+- **Reviewable output:** Runs preserve branches, worktrees, logs, and evidence;
+  completed work comes back as commits. You keep control of the repository and
+  the final release.
 
-You need **Node.js 20.18.1+**, **Git**, **Docker running**, and **Codex or Claude Code**
-with a subscription login or API key.
+## Install and run
 
-Run:
+Before running Shipyard, install the [Snappedly skills](https://github.com/snappedly/skills)
+and run `setup-snapedly-skills` in the target repository.
 
-```sh
-npx skills add snappedly/skills
-```
-
-Ask your coding agent to run `setup-snappedly-skills` in that repository.
+Requirements: Node.js 20.18.1+, Git, Docker, and credentials for your chosen
+agent. Run these commands in the repository Shipyard should change:
 
 ```sh
 npm install --save-dev @snappedly-tools/shipyard
 npx shipyard init
 ```
 
-During `shipyard init`, choose your agent, **Docker**, the template you want, and install the optional
-[repository runner](docs/content/docs/repository-runner.mdx). Follow
-the authentication prompts.
+`init` asks for the agent, authentication, sandbox, issue tracker, and workflow
+template, then creates `.shipyard/`. For the first run, choose Docker and
+`blank` or `sequential-reviewer`.
 
-On a local Mac, the repository runner automatically wakes Shipyard when you label an issue.
-It runs as long as its terminal stays open.
+Add the requested credentials to `.shipyard/.env`, write a task in
+`.shipyard/prompt.md` when using the `blank` template, then run:
 
-See the [getting started guide](docs/content/docs/index.mdx) for authentication and
-branch options.
-
-Fill in any credentials required in `.shipyard/.env`.
-`GH_TOKEN` in `.shipyard/.env` to a GH token with Contents, Issues, and Pull
-Requests read/write access and Metadata read access.
-Set `SHIPYARD_ROUTINE_MODEL` and `SHIPYARD_STRONG_MODEL` in `.shipyard/.env`
-for the roles your template uses. `simple-loop` uses routine for triage and
-implementation. `sequential-reviewer` also uses strong for issue reviews.
-Parallel planner templates use routine for ticket work and strong for planning,
-conflict resolution, and integration. The review-enabled planner also uses
-strong for ticket and final specification reviews. See
-[agent setup](docs/content/docs/agents.mdx).
+```sh
+npx shipyard run
+```
 
-Commit the setup and prompt so the sandbox can read them. Make sure the Git ignore file keeps
-`.shipyard/.env` out of the commit.
+The first run builds the Docker image automatically. Reuse it when the
+Dockerfile has not changed:
 
 ```sh
-npx shipyard run
+npx shipyard run --skip-build
 ```
 
-Or for the automated runner:
+For Codex, `init` can sign in with a ChatGPT subscription or configure an OpenAI
+API key. Claude Code supports a subscription token or an Anthropic API key. See
+the [agent guide](docs/content/docs/agents.mdx) for authentication details.
+
+## Pick the workflow you need
+
+| Template                       | Best for              | Built-in flow                                 |
+| ------------------------------ | --------------------- | --------------------------------------------- |
+| `blank`                        | One custom task       | One agent run                                 |
+| `simple-loop`                  | A small issue backlog | Implement issues sequentially → review PRs    |
+| `sequential-reviewer`          | Safer issue delivery  | Implement → review → review PR                |
+| `parallel-planner`             | Independent issues    | Plan → implement in parallel → review PRs     |
+| `parallel-planner-with-review` | Maximum autonomy      | Plan → implement and review in parallel → PRs |
+
+All templates are generated TypeScript. Adjust prompts, models, iteration
+limits, branch strategy, hooks, and checks in `.shipyard/main.ts` or
+`.shipyard/main.mts`.
+
+## Keep a repository running
+
+On Apple Silicon macOS, the optional repository runner keeps a foreground
+Shipyard controller ready for GitHub Issues. Label an issue `shipyard`; the
+controller wakes, drains a finite batch of eligible work, coalesces duplicate
+wake-ups, and stops when it makes no progress. Restarting it recovers work
+labelled while the host was offline.
+GitHub-backed `shipyard init` provisions `shipyard`, `shipyard:blocked`,
+`shipyard:pending`, `shipyard:complete`, and `shipyard:outstanding-tasks` in the repository.
+It also provisions the `bug`, `enhancement`, and five triage state labels.
+For a connected repository, init reports an error if any label cannot be created.
+
+The bundled issue workflows install Snappedly skills and the candidate's
+dependencies in Docker. When Shipyard takes an activated ticket, it runs
+`/triage` first and checks the current GitHub labels. Implementation requires
+both `shipyard` and `ready-for-agent`, with no conflicting triage state. Other
+triage outcomes follow the normal blocked flow: Shipyard adds
+`shipyard:blocked`, removes `shipyard`, and records the reason on the ticket.
+A standalone ready issue then runs through `/implement`. Activating
+a planning spec or a linked executable child resolves the parent and only
+linked tickets labelled `shipyard` into one `/implement-spec` scope. The sequential
+templates deliver selected tickets on one branch; the parallel templates assign
+ready tickets to `/implement` workers, integrate dependency waves, resolve ticket
+merge conflicts on the spec branch, and review the integrated change. One
+non-draft PR per spec awaits human merge. Later selected tickets update that PR.
+Shipyard also recognizes a ticket added to an open verified spec PR's `Source
+issues:` line as belonging to that spec, even without a GitHub sub-issue or
+`## Parent` link. Conflicting links block the selected ticket for correction.
+Selected tickets receive `shipyard:pending` while Shipyard works on them.
+Successful handoff replaces it with `shipyard:complete` and removes `shipyard`.
+The parent spec and PR show `shipyard:blocked` if an unfinished child is blocked,
+`shipyard:outstanding-tasks` if children remain, or `shipyard:complete` when all
+linked tickets are complete. Spec labels report child state; they never prevent
+a reactivated child from running. The issues remain open under the target
+repository's closure policy.
+With no labelled tickets yet, Shipyard marks the parent outstanding and waits
+to create the PR until a ticket is selected.
+If an attempted issue cannot be completed, Shipyard comments with the reason,
+marks the attempted tickets `shipyard:blocked`, clears `shipyard:pending`, and
+removes `shipyard` from the scope. The parent spec and any existing PR show
+`shipyard:blocked` while an unfinished child remains blocked. It does not
+publish a new PR for failed work. Resolve the problem, remove
+`shipyard:blocked` from a ticket, then add `shipyard` to retry that ticket;
+the parent spec's status label needs no manual change. Missing or ambiguous
+relationships block the affected selected issue and record the reason. If GitHub cannot confirm whether a
+PR became ready, Shipyard leaves the issue active for reconciliation. The GitHub token
+needs Contents, Issues, and Pull requests read/write permission plus Metadata
+read permission. Keep the Mac and foreground controller running for wake-ups.
+If GitHub rejects a failure comment, Shipyard keeps a local pending report for
+replay. A fresh `shipyard` activation on an unblocked ticket supersedes that
+report. Spec and PR status label failures are logged without stopping ticket
+work; retained activation lets the next invocation recalculate their labels.
+
+Accept runner installation during `init`, or install it later:
 
 ```sh
+npx shipyard runner install
+git add .shipyard .github/workflows/shipyard-wake.yml
+git commit -m "Add Shipyard wake workflow"
+git push
 npx shipyard runner start
 ```
 
-## Turn GitHub issues into pull requests
+Run `npx shipyard runner purge` to remove every dated run-log folder and
+root-level `.log` file under `.shipyard/logs/`. Shipyard automatically removes
+entries older than eight days before `shipyard run`, at runner startup, and
+daily while the runner stays active. Use a path outside `.shipyard/logs/` for
+logs that must be retained separately.
+
+See the [repository runner guide](docs/content/docs/repository-runner.mdx) for
+requirements, lifecycle commands, and the security model.
 
-Then:
+## Build your own coordinator
+
+Shipyard is also a TypeScript library. Compose your own workflow with
+`run()`, `createSandbox()`, and `createWorktree()` while reusing its agent,
+sandbox, branch, prompt, logging, cancellation, and session primitives.
+
+```ts
+import { CODEX_MODELS, codex, run } from "@snappedly-tools/shipyard";
+import { docker } from "@snappedly-tools/shipyard/sandboxes/docker";
+
+await run({
+  agent: codex(CODEX_MODELS.routine),
+  sandbox: docker(),
+  promptFile: ".shipyard/prompt.md",
+});
+```
+
+Docker is the default path. Vercel Sandbox is available for isolated cloud
+execution; `noSandbox()` is available only for trusted repositories and prompts.
+
+## What gets created
+
+```text
+.shipyard/
+├── main.ts or main.mts   # workflow configuration
+├── prompt.md              # task or issue instructions
+├── Dockerfile             # sandbox image definition
+├── .env                   # untracked credentials
+├── logs/                  # run logs
+├── worktrees/             # isolated branch worktrees
+└── patches/               # recovery artifacts
+```
 
-1. Write an issue with a clear goal and add the `shipyard` and
-   `ready-for-agent` labels.
-2. Make sure the runner is running, or start `npx shipyard run`. Shipyard checks the issue, implements it in Docker,
-   reviews the work, and opens a pull request.
-3. Inspect the pull request and merge it when you are happy with the result.
+## Security and control
 
-## Choose a workflow
+Docker keeps the agent's repository and Git storage inside the sandbox by
+default. It is not a magic security boundary: mounts, credentials, devices,
+network access, host hooks, and `noSandbox()` can expand what an agent can do.
+Use least-privilege credentials and review generated configuration before
+running untrusted code. Read the [security evaluation](docs/security-evaluation.md)
+and [SECURITY.md](SECURITY.md).
 
-| Template                       | What it does                                       |
-| ------------------------------ | -------------------------------------------------- |
-| `simple-loop`                  | Works through labeled issues one at a time.        |
-| `sequential-reviewer`          | Implements and reviews issues before PR handoff.   |
-| `parallel-planner`             | Plans and works on independent issues in parallel. |
-| `parallel-planner-with-review` | Adds review to the parallel workflow.              |
+Shipyard runs in your infrastructure. There is no required hosted control
+plane; you control the host, Docker, model access, logs, and release policy.
 
-Shipyard also exports TypeScript APIs for custom workflows. Configure prompts,
-branches, limits, and hooks in the generated `.shipyard/main.ts` or
-`.shipyard/main.mts`. See [configuration](docs/content/docs/configuration.mdx)
-and [agent setup](docs/content/docs/agents.mdx).
+## Learn more
 
-## Safety and license
+- [Getting started](docs/content/docs/index.mdx)
+- [Configuration](docs/content/docs/configuration.mdx)
+- [Repository runner operations](docs/runbooks/repository-runner-macos-validation.md)
+- [Contributing](CONTRIBUTING.md)
 
-Shipyard runs on your machine or infrastructure. Sandbox access depends on the
-mounts, credentials, and network settings you choose. Read the
-[security guide](docs/security-evaluation.md) before using untrusted code.
+## License
 
-Shipyard is source-available under the [PolyForm Strict License 1.0.0](LICENSE)
-for permitted noncommercial use. Contact Snappedly for a commercial license.
+Shipyard is source-available under the
+[PolyForm Strict License 1.0.0](LICENSE). It is available for permitted
+noncommercial use; the license does not permit redistribution, modification, or
+derivative works. Contact Snappedly to request a commercial license.

package/dist/MountConfig-bZoCs4Dd.d.ts

@@ -0,0 +1,26 @@
+/**
+ * User-facing mount configuration for bind-mount sandbox providers.
+ *
+ * Each entry describes a host directory to mount into the sandbox container.
+ */
+/** A single bind-mount descriptor for the Docker provider. */
+interface MountConfig {
+    /**
+     * Path on the host. Supports:
+     * - Absolute paths (`/data/cache`)
+     * - Tilde-expanded paths (`~/data` → `<home>/data`)
+     * - Relative paths (`data` or `./data`) — resolved from `process.cwd()`
+     */
+    readonly hostPath: string;
+    /**
+     * Path inside the sandbox container. Supports:
+     * - Absolute paths (`/mnt/data`)
+     * - Tilde-expanded paths (`~/.npm` → `/home/agent/.npm`) — expanded using the provider's sandbox home directory
+     * - Relative paths (`data` or `./data`) — resolved from the worktree directory (`/home/agent/workspace`)
+     */
+    readonly sandboxPath: string;
+    /** Mount as read-only. Defaults to `false`. */
+    readonly readonly?: boolean;
+}
+
+export type { MountConfig as M };

package/dist/SandboxProvider-XJQqEdSf.d.ts

@@ -0,0 +1,261 @@
+/**
+ * Sandbox provider types — the pluggable interface for sandbox runtimes.
+ *
+ * Provider authors implement a small Promise-based interface. Shipyard
+ * handles worktree creation, git mount resolution, and commit extraction.
+ */
+/** Result of executing a command inside a sandbox. */
+interface ExecResult {
+    readonly stdout: string;
+    readonly stderr: string;
+    readonly exitCode: number;
+}
+/** Options for interactiveExec — the streams the provider should wire to the spawned process. */
+interface InteractiveExecOptions {
+    readonly stdin: NodeJS.ReadableStream;
+    readonly stdout: NodeJS.WritableStream;
+    readonly stderr: NodeJS.WritableStream;
+    readonly cwd?: string;
+    /** Terminate the interactive process when the caller cancels the session. */
+    readonly signal?: AbortSignal;
+}
+/** Handle to a running bind-mount sandbox. */
+interface BindMountSandboxHandle {
+    /** Absolute path to the worktree inside the sandbox. */
+    readonly worktreePath: string;
+    /**
+     * Execute a command in the sandbox.
+     *
+     * Implementations MUST support line-by-line streaming via `onLine`. This is
+     * how Shipyard delivers live feedback to the user and enforces idle timeouts —
+     * without a streaming implementation, neither will work. A buffered/batch
+     * implementation that only calls `onLine` after the process exits does NOT
+     * satisfy this contract.
+     *
+     * When `stdin` is set, the implementation pipes the string to the child
+     * process's stdin and closes it. This avoids the Linux 128 KB per-arg limit.
+     */
+    exec(command: string, options?: {
+        onLine?: (line: string) => void;
+        cwd?: string;
+        sudo?: boolean;
+        stdin?: string;
+        /** Abort the command when the caller's operation is cancelled. */
+        signal?: AbortSignal;
+        /** Reject/terminate the command after this many combined output bytes. */
+        maxOutputBytes?: number;
+    }): Promise<ExecResult>;
+    /**
+     * Launch an interactive process inside the sandbox.
+     * Optional — providers that support interactive sessions implement this.
+     * The provider detects TTY mode from the streams (e.g. stdin.isTTY) and
+     * allocates a pseudo-terminal accordingly.
+     * Implementations MUST terminate the underlying process when `signal` aborts.
+     */
+    interactiveExec?(args: string[], options: InteractiveExecOptions): Promise<{
+        exitCode: number;
+    }>;
+    /** Copy a single file from the host into the sandbox. */
+    copyFileIn(hostPath: string, sandboxPath: string): Promise<void>;
+    /** Copy a single file from the sandbox to the host. */
+    copyFileOut(sandboxPath: string, hostPath: string): Promise<void>;
+    /** Tear down the sandbox. */
+    close(): Promise<void>;
+}
+/** Options passed to a bind-mount provider's `create` function. */
+interface BindMountCreateOptions {
+    /** Host-side path to the worktree directory. */
+    readonly worktreePath: string;
+    /** Host-side path to the original repo root. */
+    readonly hostRepoPath: string;
+    /** Volume mounts to apply (host:sandbox pairs). */
+    readonly mounts: Array<{
+        hostPath: string;
+        sandboxPath: string;
+        readonly?: boolean;
+    }>;
+    /** Environment variables to inject into the sandbox. */
+    readonly env: Record<string, string>;
+}
+/** Configuration for createBindMountSandboxProvider. */
+interface BindMountSandboxProviderConfig {
+    /** Human-readable name for this provider (e.g. "docker"). */
+    readonly name: string;
+    /** Environment variables injected by this provider. Merged at launch time. */
+    readonly env?: Record<string, string>;
+    /**
+     * Absolute path to the home directory inside the sandbox (e.g. `"/home/agent"`).
+     * Used to expand `~` in user-provided `sandboxPath` mount configs.
+     * Set to `undefined` for providers that do not have a fixed home directory.
+     */
+    readonly sandboxHomedir?: string;
+    /** Create a sandbox handle from the given options. */
+    readonly create: (options: BindMountCreateOptions) => Promise<BindMountSandboxHandle>;
+}
+/** Handle to a running isolated sandbox (extends bind-mount with file transfer). */
+interface IsolatedSandboxHandle {
+    /** Absolute path to the worktree inside the sandbox. */
+    readonly worktreePath: string;
+    /**
+     * Execute a command in the sandbox.
+     *
+     * Implementations MUST support line-by-line streaming via `onLine`. This is
+     * how Shipyard delivers live feedback to the user and enforces idle timeouts —
+     * without a streaming implementation, neither will work. A buffered/batch
+     * implementation that only calls `onLine` after the process exits does NOT
+     * satisfy this contract.
+     *
+     * When `stdin` is set, the implementation pipes the string to the child
+     * process's stdin and closes it. This avoids the Linux 128 KB per-arg limit.
+     */
+    exec(command: string, options?: {
+        onLine?: (line: string) => void;
+        cwd?: string;
+        sudo?: boolean;
+        stdin?: string;
+        /** Abort the command when the caller's operation is cancelled. */
+        signal?: AbortSignal;
+        /** Reject/terminate the command after this many combined output bytes. */
+        maxOutputBytes?: number;
+    }): Promise<ExecResult>;
+    /**
+     * Launch an interactive process inside the sandbox.
+     * Optional — providers that support interactive sessions implement this.
+     * The provider detects TTY mode from the streams (e.g. stdin.isTTY) and
+     * allocates a pseudo-terminal accordingly.
+     * Implementations MUST terminate the underlying process when `signal` aborts.
+     */
+    interactiveExec?(args: string[], options: InteractiveExecOptions): Promise<{
+        exitCode: number;
+    }>;
+    /** Copy a file or directory from the host into the sandbox. */
+    copyIn(hostPath: string, sandboxPath: string): Promise<void>;
+    /** Copy a single file from the sandbox to the host. */
+    copyFileOut(sandboxPath: string, hostPath: string): Promise<void>;
+    /** Tear down the sandbox. */
+    close(): Promise<void>;
+}
+/** Options passed to an isolated provider's `create` function. */
+interface IsolatedCreateOptions {
+    /** Original host repository path, used only for image naming; never mounted. */
+    readonly hostRepoPath?: string;
+    /** Environment variables to inject into the sandbox. */
+    readonly env: Record<string, string>;
+}
+/** Configuration for createIsolatedSandboxProvider. */
+interface IsolatedSandboxProviderConfig {
+    /** Human-readable name for this provider (e.g. "vercel"). */
+    readonly name: string;
+    /** Environment variables injected by this provider. Merged at launch time. */
+    readonly env?: Record<string, string>;
+    /** Create an isolated sandbox handle from the given options. */
+    readonly create: (options: IsolatedCreateOptions) => Promise<IsolatedSandboxHandle>;
+}
+/** A bind-mount sandbox provider. */
+interface BindMountSandboxProvider {
+    /** Human-readable provider name. */
+    readonly name: string;
+    /** Environment variables injected by this provider. */
+    readonly env: Record<string, string>;
+    /**
+     * Absolute path to the home directory inside the sandbox (e.g. `"/home/agent"`).
+     * `undefined` when the provider does not declare a sandbox home directory.
+     */
+    readonly sandboxHomedir: string | undefined;
+}
+/** An isolated sandbox provider. */
+interface IsolatedSandboxProvider {
+    /** Human-readable provider name. */
+    readonly name: string;
+    /** Environment variables injected by this provider. */
+    readonly env: Record<string, string>;
+}
+/** Handle to a no-sandbox session — runs commands directly on the host. */
+interface NoSandboxHandle {
+    /** Absolute path to the worktree on the host. */
+    readonly worktreePath: string;
+    /**
+     * Execute a command on the host.
+     *
+     * Implementations MUST support line-by-line streaming via `onLine`. This is
+     * how Shipyard delivers live feedback to the user and enforces idle timeouts —
+     * without a streaming implementation, neither will work.
+     *
+     * When `stdin` is set, the implementation pipes the string to the child
+     * process's stdin and closes it. This avoids the Linux 128 KB per-arg limit.
+     */
+    exec(command: string, options?: {
+        onLine?: (line: string) => void;
+        cwd?: string;
+        sudo?: boolean;
+        stdin?: string;
+        /** Abort the command when the caller's operation is cancelled. */
+        signal?: AbortSignal;
+        /** Reject/terminate the command after this many combined output bytes. */
+        maxOutputBytes?: number;
+    }): Promise<ExecResult>;
+    /**
+     * Launch an interactive process on the host with inherited stdio.
+     */
+    interactiveExec(args: string[], options: InteractiveExecOptions): Promise<{
+        exitCode: number;
+    }>;
+    /** No-op — no container to tear down. */
+    close(): Promise<void>;
+}
+/** A no-sandbox provider — runs the agent directly on the host with no container isolation. */
+interface NoSandboxProvider {
+    /** Human-readable provider name. */
+    readonly name: string;
+    /** Environment variables injected by this provider. */
+    readonly env: Record<string, string>;
+}
+/** Head strategy: agent writes directly to host working directory. Bind-mount only. */
+interface HeadBranchStrategy {
+    readonly type: "head";
+}
+/** Merge-to-head strategy: temp branch, merge back to HEAD, delete temp branch. */
+interface MergeToHeadBranchStrategy {
+    readonly type: "merge-to-head";
+}
+/** Branch strategy: commits land on an explicit named branch. */
+interface NamedBranchStrategy {
+    readonly type: "branch";
+    readonly branch: string;
+    /**
+     * Git ref to use as the starting point when creating a new branch.
+     * Only used when the branch doesn't already exist — ignored otherwise.
+     * Callers are responsible for ensuring the ref is current (e.g. `git fetch`).
+     * Defaults to `HEAD` when omitted.
+     */
+    readonly baseBranch?: string;
+}
+/** Branch strategy for bind-mount providers (all three variants). */
+type BindMountBranchStrategy = HeadBranchStrategy | MergeToHeadBranchStrategy | NamedBranchStrategy;
+/** Branch strategy for isolated providers (no head — can't write to host). */
+type IsolatedBranchStrategy = MergeToHeadBranchStrategy | NamedBranchStrategy;
+/** Branch strategy for no-sandbox providers (all three — same as bind-mount). */
+type NoSandboxBranchStrategy = HeadBranchStrategy | MergeToHeadBranchStrategy | NamedBranchStrategy;
+/** Union of all branch strategy variants. */
+type BranchStrategy = BindMountBranchStrategy | IsolatedBranchStrategy | NoSandboxBranchStrategy;
+/**
+ * A sandbox provider — the pluggable unit that `run()`, `interactive()`, and
+ * `createSandbox()` accept. Tagged for internal dispatch: "bind-mount",
+ * "isolated", or "none". When `NoSandboxProvider` is used, the agent runs
+ * directly on the host with no container isolation — opt in at your own risk.
+ */
+type SandboxProvider = BindMountSandboxProvider | IsolatedSandboxProvider | NoSandboxProvider;
+/** @deprecated Use `SandboxProvider` — it now includes `NoSandboxProvider`. */
+type AnySandboxProvider = SandboxProvider;
+/**
+ * Create a bind-mount sandbox provider from a config object.
+ * The returned provider can be passed to `run()` or `createSandbox()`.
+ */
+declare const createBindMountSandboxProvider: (config: BindMountSandboxProviderConfig) => BindMountSandboxProvider;
+/**
+ * Create an isolated sandbox provider from a config object.
+ * The returned provider can be passed to `run()` or `createSandbox()`.
+ */
+declare const createIsolatedSandboxProvider: (config: IsolatedSandboxProviderConfig) => IsolatedSandboxProvider;
+
+export { type AnySandboxProvider as A, type BindMountSandboxHandle as B, type ExecResult as E, type HeadBranchStrategy as H, type IsolatedSandboxProvider as I, type MergeToHeadBranchStrategy as M, type NoSandboxProvider as N, type SandboxProvider as S, type BranchStrategy as a, type NamedBranchStrategy as b, type BindMountBranchStrategy as c, type BindMountCreateOptions as d, type BindMountSandboxProvider as e, type BindMountSandboxProviderConfig as f, type InteractiveExecOptions as g, type IsolatedBranchStrategy as h, type IsolatedCreateOptions as i, type IsolatedSandboxHandle as j, type IsolatedSandboxProviderConfig as k, type NoSandboxBranchStrategy as l, type NoSandboxHandle as m, createBindMountSandboxProvider as n, createIsolatedSandboxProvider as o };

package/dist/{chunk-JI3HDDMS.js → chunk-56TDSWFU.js}

@@ -1,4 +1,4 @@
-import { CONFIG_DIR, ConfigDirError, assertNoSymlinkComponents, LOGS_DIR, Display } from './chunk-L6PX5QTU.js';
+import { CONFIG_DIR, ConfigDirError, assertNoSymlinkComponents, LOGS_DIR, Display } from './chunk-FDYOTN55.js';
 import { Effect } from 'effect';
 import { FileSystem } from '@effect/platform';
 import { join } from 'path';
@@ -251,5 +251,5 @@ var purgeRunLogs = async (options) => {
 };
 
 export { CODEX_MODELS, CODEX_REASONING_EFFORTS, DEFAULT_LOG_RETENTION_DAYS, buildLogDirectoryName, formatErrorMessage, purgeRunLogs, resolveEnv, withFriendlyErrors };
-//# sourceMappingURL=chunk-JI3HDDMS.js.map
-//# sourceMappingURL=chunk-JI3HDDMS.js.map
+//# sourceMappingURL=chunk-56TDSWFU.js.map
+//# sourceMappingURL=chunk-56TDSWFU.js.map