Tianyi Cui
ebcfab1621
pkg stores application files in a virtual filesystem, and its worker_threads hook discovers worker entry points only when they are passed as filesystem strings. Convert the code-runtime entry with fileURLToPath() and return the workflow built entry as a string while retaining its source-mode data URL bootstrap. Emit worker entry bundles as CommonJS .cjs files. pkg executes a VFS-backed string-path worker through Module._compile, so an ESM-only entry can be present in the executable yet still fail when launched. Keep the public hosts ESM, adapt worker startup accordingly, and align exports, package file lists, workspace constraints, documentation, and built-worker tests with the actual artifact format. Expand the custom-config executable smoke to load the Code Mode and workflow plugins and script real run_code and zero-agent workflow calls. Require both tools to return 42 from workers launched inside the pkg VFS, turning worker support from an asset-presence assumption into an end-to-end runtime contract. Update the implemented RFC and verification gates to describe and exercise the supported built-worker path. This adds no tool or JSON-RPC protocol shape; it fixes how existing worker-backed capabilities are located and executed in the single-file distribution.
code-runtime/ — code-execution capability family
The code-execution capability seam (see capability seams): an abstract runtime interface for executing one model-written program against host-provided async bindings, capturing what it printed and returned. The consumer is the tool registry's Code Mode (tools: { mode: code } — the run_code tool and the generated TypeScript SDK); design in the Code Mode RFC. Product packages.
| Package | Role | ctx key |
|---|---|---|
code-runtime/ |
Abstract code-execution seam (interface + vocabulary) | ctx.codeRuntime |
code-runtime-worker/ |
Worker-thread backend: fresh worker per run, TypeScript via host-side type-strip (annotations advisory, never type-checked), port-bridged bindings, budget/heap containment | registers ctx.codeRuntime |
The interface lives at code-runtime/code-runtime/; the shipped backend at code-runtime/code-runtime-worker/. Backends differ by execution substrate (worker thread, process, container) and by source language — both readonly descriptors on the service — and register ctx.codeRuntime without touching the interface or its consumer; that split is what makes a hardened backend a drop-in later.