Files
deepseek-harness/docs/core-data-structures/code-runtime.md
2026-07-19 12:25:40 +08:00

6.6 KiB

Code Runtime

The code-execution seam — a capability seam whose interface (dsh-code-runtime, ctx.codeRuntime) runs one model-written program against host-provided async bindings and reports what it printed and returned. Code execution is one optional capability, not part of the agent-loop spine — so its vocabulary lives here, not in core.md. Backends differ by execution substrate and source language, both readonly descriptors on the service; the worker-thread backend and the tool-registry consumer (Code Mode) are specified in the Code Mode RFC.

Source: packages/code-runtime/code-runtime/src/types.ts

The run: request in, result out

A CodeRunRequest carries everything the runtime acts on — per the "explicit > implicit at package seams" rule, defaulting (time budgets, output caps) is the implementation's validated config, never a hidden ?? inside run():

/**
 * One run: the program source plus everything the runtime acts on. Per the
 * explicit-over-implicit convention, defaulting (time budgets, output caps)
 * is the implementation's validated config — a request carries no optional
 * tuning knobs for a hidden `??` to fill in.
 */
interface CodeRunRequest {
  /**
   * The program source, in the runtime's {@link ../index.ts | language}. It
   * runs as the body of an async function: top-level `await` and `return`
   * are available, and the completion value becomes
   * {@link CodeRunResult.value}.
   */
  program: string
  /** Host functions exposed to the program, one global object per namespace. */
  bindings: CodeBindingNamespace[]
  /**
   * Abort the run: the runtime stops the program (hard, even mid-loop) and
   * resolves with a {@link CodeRunFailure} of kind `'abort'`. In-flight
   * binding calls are the CALLER's to settle — the runtime only stops asking.
   */
  signal?: AbortSignal
}

The result reports an error as a field, never a rejection of run() — reporting a failed program is the caller's job, not an exception path (mirroring BashExecutor.run's resolve-on-failure contract):

/**
 * The outcome of one run. An error is a FIELD on a resolved result, never a
 * rejection of `run()` — reporting a failed program is the caller's job, not
 * an exception path.
 */
interface CodeRunResult {
  /**
   * The program's completion value (its top-level `return`), when it ran to
   * completion and the value survived the runtime's serialization boundary;
   * a non-transferable value is replaced by a string rendering, and a failed
   * or value-less run leaves this absent.
   */
  value?: unknown
  /** Text the program emitted, in order (capped by the implementation). */
  logs: string[]
  /** Present iff the run failed; see {@link CodeRunFailure} for the taxonomy. */
  error?: CodeRunFailure
}

Bindings: host functions as program globals

Each CodeBindingNamespace becomes one global object of async callables inside the program (the Code Mode consumer passes one: tools). Arguments and resolutions must be structured-cloneable — a runtime may bridge calls across a serialization boundary — and a runtime treats binding names as hostile input (__proto__ is an ordinary own property, never a prototype collision):

/**
 * A named group of {@link CodeBindingFunction}s the runtime exposes to the
 * program as one global object (e.g. `tools`). Function names are arbitrary
 * strings — a runtime must treat names like `__proto__` or `constructor` as
 * ordinary own properties (null-prototype construction), never as prototype
 * collisions.
 */
interface CodeBindingNamespace {
  /** The global identifier the program sees (must be a valid JS identifier). */
  global: string
  /** The callable members, keyed by the exact name the program calls. */
  functions: Record<string, CodeBindingFunction>
}
/**
 * One host-side function exposed to the program as an async callable. The
 * runtime bridges calls to it (possibly across a serialization boundary), so
 * `args` and the resolution value MUST be structured-cloneable; a runtime
 * rejects a non-cloneable value with a descriptive error rather than
 * corrupting the run. A rejection of this function surfaces inside the
 * program as a rejection of the corresponding call.
 */
type CodeBindingFunction = (args: unknown) => Promise<unknown>

Captured output and the failure taxonomy

Logs are plain strings in emission order. The runtime captures the program's console and stream output, but channel and console-method metadata are not part of the seam because consumers render only the text. Implementations cap the aggregate output and mark truncation in-band.

Failure kinds are orthogonal outcomes reported independently (per defensive-patterns): a budget expiry is not an exception, an abort is not a timeout, and a substrate death (e.g. OOM) is neither:

/**
 * Why a run failed. The kinds are orthogonal outcomes reported independently
 * (per docs/defensive-patterns.md): a budget expiry is not an exception, an
 * abort is not a timeout, and a substrate death is neither.
 *
 * - `'exception'` — the program threw or failed to parse/transform.
 * - `'timeout'` — an implementation-owned budget expired; the message says which.
 * - `'abort'` — {@link CodeRunRequest.signal} fired.
 * - `'worker-exit'` — the execution substrate died without settling (e.g. OOM).
 */
interface CodeRunFailure {
  /** The failure class (see the interface doc for each kind's meaning). */
  kind: 'exception' | 'timeout' | 'abort' | 'worker-exit'
  /** Human-readable detail, suitable for feeding back to a model to self-correct. */
  message: string
}

The service

CodeRuntime (ctx.codeRuntime, abstract — defined in packages/code-runtime/code-runtime/src/index.ts) is run(request) plus two readonly descriptors: language (what the program must be written in — 'typescript' is the well-known value; a consumer generating language-specific presentation switches on it and fails loud on one it cannot present) and isolation (the execution substrate — 'worker-thread', 'process', 'container'; a diagnostic label, not a security claim). Implementations must keep runs isolated from each other (no cross-run state) and dispose to quiescence: in-flight runs are terminated and awaited before teardown completes.