codex exec review ends without output after a fixed timeout and automation cannot distinguish the timeout

What issue are you seeing?

codex exec review appears to have a fixed wall-clock timeout in the review task (120s warning, 300s stop in core/src/tasks/review.rs). When that budget is hit, the review ends as a generic interruption / ended without review output, which makes it hard to distinguish:

• provider slowness
• a review loop that is still making progress
• an actual review/tooling failure

This is especially painful for automation. In practice, a long-running review often looks like a clean command exit that simply never produced a verdict.

I also hit a related automation gap in JSON mode: there is no structured timeout-specific terminal signal for review timeouts, so scripts cannot reliably tell the difference between "review timed out while still making progress" and a generic interrupted review.

What steps can reproduce the bug?

1. Start from any repo with uncommitted changes.
2. Run codex exec review --uncommitted.
3. If the review does not finish within the hard-coded budget, it ends without a review verdict.
4. Run the same command with --json and observe that automation gets a generic interrupted / ended-without-output outcome rather than a distinct timeout result.

Concrete local evidence from today:

• A temporary repo with a fork-local proof-of-concept timeout override set to 1000ms timed out after 1 second.
• The same repo with the override set to 3000ms timed out after 3 seconds.
• A scoped self-review in the Codex repo against a handful of touched files timed out after 15 seconds and 30 seconds while still showing recent shell activity (processing shell command results, then streaming shell command output).

Those runs strongly suggest the missing piece is not just "longer timeout", but a better timeout model + clearer signaling.

What is the expected behavior?

At minimum:

• review timeouts should surface a distinct timeout reason instead of collapsing to a generic interrupted / ended-without-output result
• the timeout reason should be visible in JSON output so automation can treat it as a tooling blocker

Ideally:

• the review timeout should be configurable
• or there should be separate startup vs active-review timeouts
• or both

The key point is that review automation needs to know whether the reviewer was still making progress when the run was cut off.

Additional information

Relevant existing issues that seem adjacent but do not cover this directly:

• #6432 headless codex exec review
• #11599 JSON output for review
• #12502 review output routing regression
• #13163 scriptable review -> fix -> repeat workflow
• #13441 phase-aware status for long-running turns

I am reporting this from the CLI variant.