Chinesezjc
8093d22164
The line-aggregating stray capture from the previous round regressed three ways the review caught. Rewrite it on the fd-3 reader's raw-Buffer-chunk shape: accumulate chunks with a byte counter and split on the raw 0x0a byte, so a large newline-free write no longer re-copies the residual and re-scans from index 0 per chunk (both O(N^2)). Meter each admitted entry by serialized cost through a new jsonStringCostUpTo that walks to the cap and stops, so a near-budget control-char-dense line never allocates the sixfold-inflated JSON.stringify result the old ledger did (the critical: ~1.6 GiB transient under a large maxLogBytes). Flush the residual explicitly in the closeDeadline handler before it destroys the streams, so a setsid escapee's path (which fires no end) does not drop a leader's final newline-free diagnostic. Harden the sync-spawn leak assertion to a set difference against a pre-run snapshot, immune to a parallel worker's concurrent tmpdir create/delete. Decline the round-2 request to enforce the fd-3 ceiling per-frame: the counter check must precede Buffer.concat to prevent ~2x memory doubling (two regression tests assert this), and the batch-edge false reject it would fix is reachable only at a maxLogBytes/maxValueBytes configured within one pipe read of the 256 MiB ceiling, far past the defaults. Documented at the check and in the note Alternatives. Add flood, NUL-flood, short-escape, and closeDeadline-flush regression tests (restoring per-file 100% coverage); update the Agent Note and zh pair.
description, kind
| description | kind |
|---|---|
| Package map for the code-execution capability family: what program execution does for you, and which package owns each part. | package-group |
code-runtime/ — code-execution capability family
English | 中文
Summary
The code-runtime/ group provides program execution: a model writes one program that calls host-provided functions as ordinary async calls, and a runtime executes it in isolation and returns only what the program printed and returned. One package defines the shared capability (ctx.codeRuntime), a second executes TypeScript programs in a fresh Node worker thread, and a third owns the wire protocol between a Node host and a CPython subprocess for the Python backend. Every run is independent — no state carries from one program to the next — and failures come back as part of the result, so the caller can see why a program failed and feed that back to the model.
Table of Contents
Packages
These three packages together provide program execution; each README describes what its part does.
| Package | Role | ctx key |
|---|---|---|
code-runtime/ |
Defines what a code runtime does: run one program against host-provided bindings and report what it printed and returned | ctx.codeRuntime |
code-runtime-worker-thread/ |
Executes TypeScript programs, each in a fresh Node worker thread | registers ctx.codeRuntime |
code-runtime-python/ |
Owns the fd-3 wire protocol between a Node host and a CPython subprocess, the Python backend's protocol layer | — |
Related documentation
Start with the subsystem reference for the service contract, then the PTC mode design that consumes this capability and the capability-seam model it follows.
- Code runtime subsystem reference — request/result vocabulary, bindings, and the
ctx.codeRuntimecordis surface. - PTC mode Agent Note — how the tool registry presents
run_codeto the model. - Capability seams — the Service Definition / Service Provider / Consumer split this family follows.
Dev Note
Working context for maintainers — click to expand
None.