Workspace container has no init, so orphaned tool processes become zombies

[marcusrbrown]

The workspace container runs node as pid 1: the entrypoint ends with exec node /app/apps/workspace-agent/dist/main.mjs, and neither deploy/compose.yaml nor deploy/workspace.Dockerfile adds an init (init: true, tini, dumb-init). Node only waits on children it spawned itself, so any orphan reparented to pid 1 is never reaped.

OpenCode's tool calls run arbitrary shells, background jobs, and double-forks. Every process they leave behind when their parent exits becomes a zombie for the life of the container. A long-running workspace can accumulate them until the pid table is exhausted, at which point fork fails for OpenCode's tools and for the service's own git.

The isolation harness shows it directly (#1661, phase 4d): after root signals a detached uid-10001 process tree, all three processes exit but remain in /proc in state Z, reparented to node. The harness now records them rather than failing on them.

This predates the uid split; it matters more now that the container is meant to run untrusted tool processes.

Fix

Add init: true to the workspace service in deploy/compose.yaml (Docker's bundled tini), and --init wherever the image is run directly in CI (WORKSPACE_DOCKER_SECURITY_FLAGS, deploy/tests/isolation-harness.sh, deploy/egress-smoke.sh). tini forwards SIGTERM, so the service's shutdown drain keeps working.

The service then stops being pid 1. The harness reads the service as /proc/1 in several places (identity, /proc/1/environ and /proc/1/mem denials, the "cannot signal the service" control); those need to target the service's real pid. deploy/validate-stack.sh should require init: true.

Acceptance: the harness's phase 4d tree is fully reaped (no Z entries), and a check asserts it.

[fro-bot]

Triage: confirmed, and the proposed fix works

Summary. The workspace container runs node as pid 1 (deploy/workspace-entrypoint.sh ends in exec node /app/apps/workspace-agent/dist/main.mjs). Nothing in deploy/compose.yaml or deploy/workspace.Dockerfile adds an init, so no process reaps orphans. Every process that OpenCode's tools leave behind stays in the pid table as a zombie until the container restarts.

Severity: medium. Nothing breaks today. On a long-lived workspace the zombies pile up, and once the pid table is full, fork fails for OpenCode's tools and for the service's own git. That risk is higher now that the container runs untrusted tool processes.

Reproduction

I ran this on the CI runner (Docker 28.0.4, node:24-alpine, node as pid 1). The test starts a detached shell with a background child, lets the shell exit, and then scans /proc for state Z:

docker run flag	pid 1	Zombies after the orphan exits
(none, as today)	MainThread (node)	ZOMBIE pid=22 ppid=1 comm=sleep
--init	docker-init (tini)	none

I also checked that graceful shutdown still works under --init. A node process with a SIGTERM handler received the signal from docker stop through tini, logged got SIGTERM, draining, and exited with code 0 in about 0.6s. The drain in apps/workspace-agent/src/main.ts:250 should behave the same way. OpenCode is a detached child that the supervisor stops itself (opencodeController.abort()), so tini forwarding signals only to its direct child makes no difference there.

Where the changes go

Most of the files named in the issue exist only on feat/workspace-agent-uid-isolation (#1661), not on main: deploy/tests/isolation-harness.sh and WORKSPACE_DOCKER_SECURITY_FLAGS are both missing from main. I'd put the fix on that branch, or in a follow-up right after it merges, so the harness assertion lands in the same change as the fix.

1. deploy/compose.yaml: add init: true to the workspace service, next to user: '0:0' / cap_drop / security_opt.
2. deploy/egress-smoke.sh: this script writes its own compose file (cat > "${SMOKE_DIR}/compose.yaml", workspace service at about line 110 on the branch). It needs init: true there, not a --init flag.
3. .github/workflows/ci.yaml: add --init to WORKSPACE_DOCKER_SECURITY_FLAGS (branch line 430) and update the comment saying it "mirrors compose.yaml exactly". On main, the workspace-smoke docker run -d calls (around lines 470–690) also need --init if part of this lands before feat(workspace): run the agent as its own unprivileged user #1661.
4. deploy/tests/isolation-harness.sh: once the service is no longer pid 1, fix every place that assumes it is:
   • Resolve SVC_PID once, as the only child of pid 1 (/proc/1/task/1/children), and check that its cmdline is node …/workspace-agent/dist/main.mjs. Also assert that /proc/1/comm is docker-init, so the check fails if someone drops the flag.
   • Identity check (line 218, cat /proc/1/status): read /proc/$SVC_PID/status instead.
   • /proc/1/environ denial (lines 427–430) and /proc/1/mem denial (line 456): target $SVC_PID. These must move. tini runs as root and has the same environment, so leaving them on /proc/1 would keep passing while testing the wrong process.
   • "Cannot signal the service" control (lines 1179–1182): kill -TERM "$SVC_PID", and check that /proc/$SVC_PID still exists afterwards.
   • The comments and log text at lines 1129 and 1152 describe node as pid 1 and need updating.
   • Acceptance check: in phase 4d, replace RECORD (not asserted) … unreaped zombie with a fail. Give it a short poll window, because tini reaps asynchronously after SIGCHLD. The check should require every tree pid to be missing from /proc, not merely "not running".
   • Yama/ptrace behaviour is unchanged: a docker exec process is still not an ancestor of the service.
5. deploy/validate-stack.sh: add an invariant that services.workspace.init is true, alongside the network and volume invariants (it already parses the file with Python). Add a negative fixture to validate-stack.test.sh.

Things to watch

• init: true needs Compose file format 2.2+ or the Compose Spec. The current Compose v2 CLI supports it.
• Adding tini to the image (apk add tini with ENTRYPOINT ["/sbin/tini","--",…]) would protect bare docker run users who forget --init. I'm not recommending it: with Docker's --init also set you'd get a double init, and the harness plus the validate-stack check already cover the "someone forgot the flag" case. This depends on whether people are expected to run the image outside compose or CI.

Next step: apply the changes above on the #1661 branch (or immediately after it merges), then confirm that the harness's phase 4d passes with the new zombie assertion enforced.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/agent
Run ID	36058261928
Cache	hit
Session	ses_f2aca757effeF78KRbTQZIszI7