codex-computer-use can stall for hours after a passing real-screenshot probe

[JorgeMenaDev]

Evidence

Andy ticket #428 required one ticket-scoped Gherkin acceptance run through codex-computer-use. The lane repeatedly stalled even after the documented daemon recovery and a passing real-screenshot probe.

Most conclusive attempt (crew/pauta-viva-428-campaign-chat-20260802/gherkin-run-4/):

• confirmed no competing codex exec process;
• killed only SkyComputerUseService PID 43600; it respawned as PID 14687;
• probe 1 failed with Sky Computer Use native pipe startup failed, empty accessibility tree, and no screenshot;
• probe 2 returned PROBE OK, a real 52,045-byte 1007x768 screenshot, and a real accessibility tree;
• App :3000, Admin :3001, and Convex :3214 were supervised and ready before launch;
• the real run then made zero browser progress for roughly two hours: 422 log lines, only 12 mcp: node_repl calls, no report.md, no screenshots, and zero Admin GET /workspaces requests.

This was the third consecutive stall after a passing probe. An earlier attempt progressed very slowly, and the next stalled during an actor switch after completing most scenarios. The ticket now has 12 observed scenarios but cannot obtain two final browser observations through the mandated lane.

Consequence

A one-shot real-screenshot probe does not establish that the subsequent Computer Use process can sustain actions. The caller receives no explicit tool error while hours pass without app requests or durable scenario progress. Repeating the documented recovery consumes additional runs without distinguishing a healthy lane from a silent stall.

Recommendation

Harden codex-computer-use at the requester/runtime boundary:

1. add a stronger preflight canary that performs at least two fresh state/action/state cycles, not only one screenshot;
2. require incremental scenario reports and an external progress watchdog keyed to durable report changes or target-app requests;
3. when no progress occurs within a bounded window, terminate the run, preserve artifacts, recover the daemon once, and resume from the first unobserved scenario rather than restarting the whole feature;
4. after the bounded recovery is exhausted, return one explicit lane-unhealthy blocker rather than encouraging repeated full runs;
5. document that Clerk localhost actor switches require signing out the current shared session before opening another __clerk_ticket login.

Do not weaken the one-Computer-Use-run-at-a-time rule or substitute Playwright/browser automation.

[JorgeMenaDev]

New operator context: Jorge reports the Mac was overheated during the repeated stalls and has now cooled. One controlled retry is underway against only the two missing scenarios. This may indicate host thermal pressure contributed; keep the issue open until the cooled retry establishes whether the post-probe stall reproduces.