Address review findings on the CPython backend: - CRITICAL: a model program could leave a descendant in the child's own process group that ignores SIGTERM but releases the inherited pipes, so the leader's `close` fired and settle() cancelled the pending SIGKILL before it escalated — run()/dispose() returned while that child lived. kill() now unrefs the grace timer and settle() no longer clears it, so the SIGKILL reaches the whole group; killGroup swallows ESRCH when the group is already gone (the normal case). Adds a real-subprocess regression test. - WARNING: the maxLogBytes/maxValueBytes load bound divided the frame ceiling by 6 for escape expansion, but both budgets are metered in already-escaped serialized bytes, so a payload occupies at most cap+envelope on the wire. Bound is now ceiling-envelope; drop the unused escape constant. - Narrow the runtime.spec.ts header to "no subprocess mocks" (it mocks node:fs.copyFileSync for staging-failure cases). - Use full-width punctuation in the README.zh.md prose per translation rules; re-record the 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.