Code Runtime

Code Runtime

Not implemented. Multiple Cloudflare enablers available.

Upstream reference: Code Runtime

What Upstream Provides

The code runtime is an optional capability seam that executes programs written by models, capturing output and return values. It is independent of the agent loop's main trunk.

• CodeRuntime (ctx.codeRuntime) — abstract service with run(request) method, language descriptor ('typescript' or 'python'), and isolation label ('worker-thread', 'process', or 'container').
• Programs run as async function bodies with top-level await and return. Host functions are exposed as global namespace objects (e.g., tools.search()).
• Failure classification: exception, timeout, abort, worker-exit (OOM), invalid-output (non-JSON), output-limit.
• Binding safety: namespace names treated as untrusted input, prototype pollution prevented, all parameters/returns must be lossless JSON.

Current Edge Status

Not Implemented No CodeRuntime service is installed. The dsh-code-runtime package is not in Edge's dependencies. Models cannot execute code snippets outside of the bash tool.

Cloudflare Enablers

Three potential implementation paths, each with different isolation guarantees and plan requirements:

Approach	Language	Isolation	Plan	Feasibility
Workers isolate	JS/TS only	V8 isolate (same as Workers)	Free	High — Edge already uses WorkerShellBackend to dispatch work to isolated Workers via the Loader binding. The same pattern could execute JS/TS snippets with host function bindings serialized across the boundary.
Dynamic Worker dispatch	JS/TS only	Separate Worker isolate	Paid	Medium — Cloudflare's Service Bindings allow dispatching to ephemeral Workers. Provides stronger isolation than in-process execution. Requires composing the code into a Worker script at runtime.
Containers	Any (Python, Node, Go, etc.)	Full Linux container	Paid (beta)	Medium — Cloudflare Containers run full Linux environments. Could host any language runtime. Higher latency (container cold start) but strongest isolation. Matches upstream's 'container' isolation label.

Existing pattern to build on: Edge's WorkerShellBackend already dispatches just-bash commands to an isolated Worker Loader binding. The same LOADER binding could be adapted to accept code snippets instead of shell commands, providing a JS/TS code runtime on the free plan with zero additional infrastructure.

Architecture Summary

Component	Category	Notes
CodeRuntime service	Missing	Not installed, no upstream package in deps
Workers isolate execution	Potential enabler	Free plan, JS/TS only, existing Loader pattern
Container execution	Potential enabler	Paid plan, any language, cold start latency

TODO

Evaluate Workers-isolate code runtime for JS/TS. The existing WorkerShellBackend + Loader binding pattern could be adapted to execute JS/TS snippets with host function bindings. This would provide a code runtime on the free plan without Containers. Key questions: Can the upstream CodeRuntime interface be satisfied with a Worker-based backend? How are host function bindings serialized across the Worker boundary? What are the memory and CPU limits per execution?

Evaluate Container-based code runtime for multi-language support. For Python and other languages, Cloudflare Containers provide full Linux environments. Key questions: What is the container cold-start latency? Can containers be reused across code runs within a session? How does this interact with the DO lifecycle (container outliving the DO activation)?