Subprocess

Subprocess

Not implemented — Edge currently uses just-bash for command execution. Native subprocess spawning is achievable via Cloudflare Containers.

Upstream reference: Subprocess

What Upstream Provides

The subprocess subsystem (ctx.subprocess) manages child process execution with explicit I/O dispositions, resource limits, and tree-scoped termination. It consists of:

• Service Definition (dsh-subprocess) — the capability seam: spawn(), spawnTerminal(), executable resolution, managed DSH_* environment namespace.
• Service Provider (dsh-subprocess-local) — the Node.js implementation using node:child_process.

Key design: the seam applies no defaults — every I/O disposition (pipe/inherit/collect), limit, and directory is explicit. Termination is tree-scoped: SIGTERM → grace period → SIGKILL across the entire process tree. waitForExit() observes all descendants before returning.

Edge Current State

Not Implemented Neither dsh-subprocess nor dsh-subprocess-local is installed. Edge cannot spawn native processes.

Command execution is handled by just-bash, a pure JavaScript shell running inside the Durable Object. It provides built-in implementations of common commands (grep, sed, awk, find, sort, diff, 20+ others) against the Computer VFS. The system prompt explicitly tells the model: "The shell is just-bash, not Linux: native binaries and background processes are unavailable."

This covers the most common agent use case (file manipulation and text processing) but cannot run compiled binaries, language runtimes (python, node), package managers (npm, pip), or build tools (make, cargo).

Cloudflare Enablers

Product	Capability	Plan Required
Cloudflare Containers	Full Linux containers attached to Workers. Can spawn native processes, install packages, run any binary. The primary enabler for a real subprocess backend.	Workers Paid or Enterprise
Cloudflare Computer	Already used by Edge for VFS. Provides the WorkerShellBackend isolated execution mode. Not full subprocess — limited to the just-bash shell.	Free (included)

Integration path: Cloudflare Containers (launched 2025) can run full Linux environments alongside a Worker. A ContainerSubprocessProvider implementing the upstream SubprocessService interface could delegate spawn() calls to a container's process namespace. The container lifecycle would be managed by the DO — start on first subprocess request, reuse across the session, terminate on session disposal.

Free plan users would continue using just-bash. The subprocess capability would be a paid-tier upgrade — the model would gain access to real python, node, git, etc. when a Container binding is configured.

Architecture Summary

Component	Category	Status
SubprocessService (ctx.subprocess)	Missing	Not installed
just-bash shell	Replace	Covers basic command execution
Container subprocess backend	Future	Cloudflare Containers (Paid)

Key observation: Subprocess is not impossible on Edge — it's gated by Cloudflare Containers, which are production-ready as of 2025. The architecture is clear: install the upstream dsh-subprocess seam, provide a Container-backed implementation, and gate it behind the Container binding availability. Free-tier users keep just-bash; paid-tier users gain real Linux processes.

TODO

Evaluate Cloudflare Containers as subprocess backend. Key questions: (1) Can a Container be spawned from a DO and its process namespace exposed? (2) What is the cold-start latency? (3) Can the upstream SubprocessService interface (spawn, spawnTerminal, terminate, waitForExit) be satisfied by Container APIs? (4) How to handle the free/paid tier split — stub provider vs real provider based on binding presence?