Worker hangs if plan-cluster or review-results never exits

[SebTardif]

A wedged plan-cluster.mjs or review-results.mjs child can pin a cluster worker forever. Codex already has CLOWNFISH_CODEX_TIMEOUT_MS. The planner and review-results spawnSync calls in scripts/run-worker.mjs have no deadline.

What happens

1. node scripts/run-worker.mjs <job.md> runs scripts/plan-cluster.mjs (and later scripts/review-results.mjs) via spawnSync with no timeout.
2. If that child never exits, the worker holds the slot until someone kills the process.

Proposed fix

Give those children the same timeout contract as Codex:

• CLOWNFISH_PLANNER_TIMEOUT_MS (default 10 minutes)
• CLOWNFISH_REVIEW_TIMEOUT_MS (default 10 minutes)
• On ETIMEDOUT, write a blocked result and exit 0 (same as the Codex timeout path)

A source test in test/run-worker-source.test.mjs checks that the timeout wiring is present.

Fork branch

This repo limits pull requests to collaborators, so I could not open a PR. The patch is on my fork:

• Branch: SebTardif:fix/planner-spawn-timeout
• Compare: main...SebTardif:fix/planner-spawn-timeout
• Commit: 32f0f1a6

Feel free to cherry-pick that commit, or I can open a PR if you add this account as a collaborator.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 15, 2026, 10:45 PM ET / August 16, 2026, 02:45 UTC.

Summary
Current main still permits planner and result-review helpers to block a cluster worker indefinitely. The report identifies a small, source-proven reliability defect with a focused repair path, so it remains necessary.

Reproducibility: yes. from current source: a planner or result-review child that does not exit will block its timeout-free spawnSync call, unlike the existing bounded Codex child path.

Next step
The affected calls, compatible failure behavior, validation path, and a contributor-supplied focused patch are all concrete enough for one repair PR.

Review details

Best possible solution:

Use bounded, positive planner and review timeout settings with conservative defaults, write one blocked result on either timeout, and cover the timeout wiring plus terminal exit path in the worker source test.

Do we have a high-confidence way to reproduce the issue?

Yes, from current source: a planner or result-review child that does not exit will block its timeout-free spawnSync call, unlike the existing bounded Codex child path.

Is this the best way to solve the issue?

Yes. Bounded helper execution with the existing blocked-result pattern is the narrowest repair; validate the new timeout values and bypass further review after a timeout.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Timeout handling must write the blocked result and exit before invoking result validation again; otherwise a timed-out review helper can still prevent terminal recovery.
• bestSolution should validate positive timeout values so an invalid environment setting cannot silently restore an unlimited child process.

Codex review notes: model internal, reasoning high; reviewed against 9f0228614de9.

Label changes

Label changes:

• add P2: A wedged helper can occupy a cluster-worker slot until external intervention, but the report does not establish a broad active outage.
• add impact:crash-loop: The affected worker process can remain unavailable indefinitely when its synchronous child never exits.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: A wedged helper can occupy a cluster-worker slot until external intervention, but the report does not establish a broad active outage.
• impact:crash-loop: The affected worker process can remain unavailable indefinitely when its synchronous child never exits.

Evidence reviewed

Acceptance criteria:

• node --test test/run-worker-source.test.mjs
• npm run validate

What I checked:

• Unbounded planner calls: Both planner invocations use spawnSync without a timeout, so a non-exiting planner prevents the worker from continuing. (scripts/run-worker.mjs:81, 9f0228614de9)
• Unbounded result validation: The result-review helper also uses spawnSync without a timeout after Codex completes. (scripts/run-worker.mjs:275, 9f0228614de9)
• Existing worker failure contract: The Codex child already has a configurable timeout and exits cleanly after writing a blocked result on ETIMEDOUT, establishing the appropriate behavior for a timed-out worker stage. (scripts/run-worker.mjs:126, 9f0228614de9)
• Workflow budget: Cluster workflows allocate 90 minutes while the existing Codex worker budget is 30 minutes, leaving room for bounded helper-stage defaults without relying solely on the workflow kill. (.github/workflows/cluster-worker.yml:267, 9f0228614de9)
• Feature-history provenance: The local path history shows the current orchestration was introduced in the recorded worker commit; no earlier distinct human owner is visible in this checkout. (scripts/run-worker.mjs:81, f8f7fa21a544)

Likely related people:

• SebTardif: The issue includes a focused fork commit for this exact worker-timeout gap. (role: reporter and proposed repair author; confidence: medium; commits: 32f0f1a685c9; files: scripts/run-worker.mjs, test/run-worker-source.test.mjs)
• github-actions[bot]: Available blame and path history attribute the current worker orchestration to its recorded commit, with no more specific historical owner present locally. (role: recent area contributor; confidence: low; commits: f8f7fa21a544; files: scripts/run-worker.mjs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.