fix(codex): release timed-out app-server lanes#94685
Conversation
|
Codex review: passed. Reviewed June 19, 2026, 2:24 AM ET / 06:24 UTC. Summary PR surface: Source +2, Tests +57. Total +59 across 3 files. Reproducibility: yes. source-level: current main gates lane-release callbacks away from plugin-owned harnesses while the queue releases only from those callbacks. The PR regression directly models a Codex timeout that never settles followed by a second same-session run. Review metrics: 1 noteworthy metric.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land this focused lane-release fix after a current-base green check run and maintainer acceptance of the late-cleanup overlap risk, while leaving WhatsApp final-error delivery to #84578. Do we have a high-confidence way to reproduce the issue? Yes, source-level: current main gates lane-release callbacks away from plugin-owned harnesses while the queue releases only from those callbacks. The PR regression directly models a Codex timeout that never settles followed by a second same-session run. Is this the best way to solve the issue? Yes, this is the best narrow fix I found: it reuses the runner-owned bounded lane-release contract and adds Codex app-server lifecycle signals instead of adding a WhatsApp-specific workaround or recovery-layer reset. The adjacent WhatsApp payload PR and diagnostic recovery PR cover different remaining surfaces. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 8480ef3f86a3. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +2, Tests +57. Total +59 across 3 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
fdd9c31 to
5e5a5d6
Compare
4424fe8 to
517c4a4
Compare
|
Clownfish 🐠 reef update Thanks for the work here. Clownfish got this branch swimming again without needing a replacement PR. Source PR: #94685 fish notes: model gpt-5.5, reasoning medium; reviewed against 517c4a4. |
|
/clownfish automerge |
|
Clownfish is on the reef for this PR. 🐠 I tagged A maintainer can call |
|
/clownfish automerge |
|
Clownfish is on the reef for this PR. 🐠 I tagged A maintainer can call |
|
🦞🔧 Source: I will update this PR branch, or open a safe credited replacement, if the repair worker finds a narrow CI fix. Automerge progress:
|
|
ClawSweeper 🐠 reef update Thanks for the contribution here. ClawSweeper could not safely push to this branch, so it opened a replacement PR from a writable branch and carried the contributor trail along with it. Why replacement: ClawSweeper could not update the source PR branch directly; GitHub did not grant sufficient push rights to the bot for that branch.
fish notes: reasoning high; reviewed against a2edc98. |
Summary
Fixes #84569 by releasing the OpenClaw command lane when a Codex app-server attempt hits its own timeout/abort path but the app-server side does not settle promptly.
Root Cause
Confirmed: the stuck lane is a root OpenClaw/Codex harness ownership bug, not a WhatsApp delivery-only bug. Current main can time out and retire/interrupt a Codex app-server turn, but the outer runner did not give plugin-owned attempts the same lane-release contract added for native runs in PR #94082. If the app-server cleanup never settled, the command lane stayed owned and later same-session work queued indefinitely.
PR #84578 remains a separate WhatsApp final-error delivery mitigation. It does not release a stuck Codex/plugin-owned lane.
Codex contract checked directly in sibling ../codex before patching: app-server v2 exposes turn/start and turn/interrupt requests plus turn/started and turn/completed notifications; turns are terminal only once they report completed/interrupted/failed rather than inProgress.
Real behavior proof
Behavior addressed: A Codex app-server attempt can time out while waiting for turn/completed, ignore cleanup/cancellation, and leave later same-session inbounds queued forever.
Real environment tested: macOS Darwin 25.5.0 arm64, Node.js v26.3.0, pnpm v11.2.2, local OpenClaw source checkout at fdd9c31.
Exact steps or command run after this patch:
Evidence after fix:
Observed result after fix: the new regression rejects the first ignored Codex timeout with CommandLaneTaskTimeoutError after the bounded grace, then the second run for the same session completes successfully, proving the lane drains.
What was not tested: live WhatsApp transport or a live external Codex app-server process wedge. The focused regression exercises the OpenClaw runner/queue contract and Codex plugin timeout hook path that caused the permanent same-session queue ownership.