/** * Sandboxed JavaScript execution tool for the agent. * * Executes user-supplied JavaScript in an isolated child process with: * - A scrubbed environment (no app secrets or env vars; only PATH/HOME/TMPDIR). * - A fresh temporary working directory. * - An ephemeral bridge HTTP server on 127.0.0.1 so the child can call * allowlisted registered tools (provider-api-request, web-request, etc.) * with the same request context as the parent — without leaking secrets. * * Security notes: * - The bridge token is a 32-byte random hex string generated per invocation. * - The bridge binds to 127.0.0.1 only; no external exposure. * - The allowlist of callable bridge tools is enforced server-side. * - Secret values are NEVER included in the env passed to the child. * - When the Node permission model is available (`--permission`, or * `--experimental-permission` on Node 20), the child is denied filesystem * access outside its own temp dir, child processes, workers, and native * addons. Outbound network from the child is NOT blocked by the permission * model; the env scrub means such requests carry no credentials, and all * authenticated calls must go through the bridge (which applies the * registered tools' host allowlists and SSRF guards). * * The actual execution is delegated to a pluggable `SandboxAdapter` (see * `./sandbox`). The default `LocalChildProcessAdapter` preserves the spawned * child-process behavior described above; a remote/durable adapter can be * plugged in via `registerSandboxAdapter()` / `AGENT_NATIVE_SANDBOX` without * changing this file. The bridge, env scrub, module building, and output * formatting stay here in the parent regardless of adapter. */ import type { ActionRunContext } from "../action.js"; import type { ActionEntry } from "../agent/production-agent.js"; export interface RunCodeOptions { /** * Extra tool names (beyond the default set) that the sandbox bridge will * forward to the registered action registry. */ bridgeTools?: string[]; } /** * Create a `run-code` ActionEntry. * * @param getActions Supplier that returns the current action registry (called * at invocation time so updates are reflected). * @param opts Optional configuration. */ export declare function createRunCodeEntry(getActions: () => Record, opts?: RunCodeOptions): ActionEntry; export interface ExecuteSandboxCodeOptions { /** Raw user JavaScript (ESM, top-level await allowed). */ code: string; /** Hard wall-clock timeout enforced by the adapter. */ timeoutMs: number; /** Supplier for the action registry the loopback bridge exposes. */ getActions: () => Record; /** Extra bridge tool names beyond the defaults. */ extraBridgeTools?: Set; /** Request context (owner/org) applied to bridged tool calls. */ context?: ActionRunContext; } export interface ExecuteSandboxCodeResult { stdout: string; stderr: string; exitCode: number | null; timedOut: boolean; bridgeToolsUsed: string[]; } /** * Run one piece of sandbox code end-to-end: start the loopback bridge, build * the scrubbed env and wrapped module, execute through the active NON-QUEUED * sandbox adapter, and return the raw outputs. This is the exact machinery the * foreground `run-code` path always used, factored out so the durable * background executor reuses it verbatim (with the enqueueing owner's context) * instead of forking it. */ export declare function executeSandboxCode(options: ExecuteSandboxCodeOptions): Promise; /** * Standalone, access-scoped poll tool for background executions. Behaviorally * identical to calling `run-code` with only `executionId`; hosts that register * it as `get-code-execution` give the model a dedicated volatile read tool (and * the enqueue guidance automatically points at it when present in the * registry). Keep the opt-out here rather than on `run-code`: repeated normal * run-code calls may execute writes or outbound requests and must retain the * agent loop's default duplicate-call protection. */ export declare function createGetCodeExecutionEntry(): ActionEntry; //# sourceMappingURL=run-code.d.ts.map