Codex CLI 0.150.1 still hangs after final output

🤖 I think #150 may have been closed too early. I upgraded Buzz's security review workflow to Codex CLI 0.150.1, but we're still seeing the same post-output hang: Codex prints the final JSON and token count, then the action never exits or emits its end marker.

Our setup is:

• GitHub-hosted ubuntu-latest
• openai/codex-action@86365089eb2b84e0a8fb0717b304f8bdcb13b20e (v1.12)
• codex-version: '0.150.1'
• gpt-5.6-sol with model_reasoning_effort=max
• safety-strategy: drop-sudo
• permission-profile: ':read-only'

The public workflow is here.

Since upgrading, 33 of 39 real review executions have stayed stuck in the Codex action until the job timeout cancelled them. Two light reviews completed and four were superseded by newer pushes. The behavior seems workload-sensitive rather than completely deterministic: the same branch and pinned versions had a clean run that finished in about three minutes, followed by a run that printed its final output but never returned.

A heavier example is run 33114428326. The Codex step started at 20:45:38Z; its completed JSON and 295,198 token count were visible by 21:14:24Z, but the action still did not exit. Run 33276058348 shows the same overall shape.

I also isolated the wrapper lifecycle in this GitHub-hosted run. It invoked the exact v1.12 production run-codex-exec path with a deterministic fake Codex process. The process wrote valid output to the wrapper-provided --output-last-message file and then kept inherited stdio open. The wrapper stayed blocked until the caller timed out the step, after which the next step could immediately read the completed file. This is synthetic, but it reproduces the lifecycle seam independently of the API/model behavior.

The v1.12 source still spawns with inherited stdout/stderr and waits on the child's close event, so a descendant retaining those descriptors can keep the action alive after the direct child is done. #151 looks like the wrapper-side fix: it uses private pipes, completes on the direct child's exit, tears down the streams, and adds a regression test for a descendant holding stdio open.

Could someone take another look at the post-0.150.0 behavior and review #151, or an equivalent wrapper fix?

Start with the v1.12 run-codex-exec path and compare it with the wrapper-side changes in #151. Reproduce the synthetic case where a descendant keeps inherited stdio open, then run the regression test described in #151. Done means the action exits after the direct child exits, closes the streams, and still reads the completed output file.