Adaptive codex timeout based on PR size and media proofs — large PRs with videos consistently time out

[scotthuang]

Problem

The default codex_timeout_ms of 600,000ms (10 minutes) is too short for large PRs, especially those with video proofs. External contributors have no way to override this timeout — the repository_dispatch payload
in dispatchItemReview() never includes codex_timeout_ms, so it always falls through to the hard default.

Concrete example

PR #91093 (openclaw/openclaw#91093) in openclaw/openclaw:

┌───────────────┬────────────────────────────────────────┐
│ Metric │ Value │
├───────────────┼────────────────────────────────────────┤
│ Files changed │ 71 │
├───────────────┼────────────────────────────────────────┤
│ Lines added │ +4,176 │
├───────────────┼────────────────────────────────────────┤
│ Commits │ 18 │
├───────────────┼────────────────────────────────────────┤
│ Video proofs │ 2 (.mov files in PR body) │
├───────────────┼────────────────────────────────────────┤
│ Codex result │ spawnSync codex ETIMEDOUT (repeatedly) │
└───────────────┴────────────────────────────────────────┘

This PR is also tagged size: XL.

Why this happens

1. Large diff context: 71 files × up to 2,000 chars per file patch = ~140KB of diff alone, plus PR body, 18 commits, timeline events, review comments, and the 760-line static prompt template.
2. Video preprocessing eats into the wall-clock budget: prepareMediaProofArtifacts() runs before codex and for each video:

• curl download (up to 90s per video via --max-time 90)
• ffprobe metadata extraction
• ffmpeg contact sheet generation

Two videos could consume up to 180s just in download, plus ffmpeg processing time — all before codex even starts. This time counts against the same outer shell timeout in sweep.yml.
3. No adaptive scaling: pr-surface-stats.ts already classifies files by type and counts additions/deletions, but this data is never used to adjust the timeout. Every PR gets the same 10 minutes regardless of 5
files or 80 files.

Suggested fixes

Option A (quick): Add codex_timeout_ms to the dispatchItemReview() client_payload, derived from PR surface stats (e.g., file count × baseline, capped at some max). This lets the workflow pick the right timeout
without any manual config.

Option B (more thorough): Factor video preprocessing time into the timeout separately — if N video proofs are detected, add N * 120s to the codex timeout budget.

Option C (architectural): Run video proof preprocessing in a separate, earlier step (e.g., in the plan job or a dedicated media job), so the review shard starts with preprocessed artifacts and the codex timeout
only covers the review itself.

Related code

• prepareMediaProofArtifacts() — src/clawsweeper.ts:6101
• proofVideoUrlsFromContext() — src/clawsweeper.ts:6059 (scans entire context JSON for .mov/.mp4/.m4v/.webm/.avi/.mkv, up to 4 URLs)
• dispatchItemReview() — src/repair/comment-webhook.ts:662 (no codex_timeout_ms in payload)
• sweep.yml:886 — timeout fallback chain, client_payload.codex_timeout_ms is always undefined for external repos
• pr-surface-stats.ts — has file classification and counts, unused for timeout decisions

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 9, 2026, 6:30 AM ET / 10:30 UTC.

Summary
Keep open; current main still uses the fixed 600000 ms default unless a dispatch or manual workflow input supplies codex_timeout_ms, media-proof preprocessing still runs before Codex, and PR surface stats are rendered for review context rather than used for timeout sizing.

Reproducibility: yes. from source inspection, though not from a live timeout run. Webhook-dispatched item reviews do not include codex_timeout_ms, sweep falls back to 600000 ms, and media-proof preprocessing runs before Codex while sharing the outer shard budget.

Next step
This is a focused automation bug with clear source, workflow, and test surfaces and no linked open implementation PR.

Review details

Best possible solution:

Add a conservative adaptive timeout calculation for PR item dispatches and failed-review retries that uses changed-file/addition counts plus detected video-proof URLs, caps total review time within sweep job limits, and preserves the 600000 ms default for small or non-media items.

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

Yes from source inspection, though not from a live timeout run. Webhook-dispatched item reviews do not include codex_timeout_ms, sweep falls back to 600000 ms, and media-proof preprocessing runs before Codex while sharing the outer shard budget.

Is this the best way to solve the issue?

Yes; the narrowest maintainable fix is to calculate and pass a bounded timeout where the PR payload is accepted, including media-proof budget, rather than increasing every review's global default.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact timeout heuristic and cap affect workflow runtime and shard throughput, so the fix should preserve the small-PR default and keep added media/diff budget bounded.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 205a27a9d70d.

Label changes

Label changes:

• add P1: The issue describes repeated Codex review timeouts on a live external PR workflow, which blocks ClawSweeper from reviewing large media-heavy contributor PRs.
• add impact:crash-loop: The affected behavior is a review worker timeout/stall before a durable review result is produced.
• 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:

• P1: The issue describes repeated Codex review timeouts on a live external PR workflow, which blocks ClawSweeper from reviewing large media-heavy contributor PRs.
• impact:crash-loop: The affected behavior is a review worker timeout/stall before a durable review result is produced.

Evidence reviewed

Acceptance criteria:

• pnpm run build
• pnpm run test:unit
• pnpm run check

What I checked:

• repository policy read: AGENTS.md was read fully; its throughput/default tuning note made the review inspect both src/clawsweeper.ts and .github/workflows/sweep.yml. (AGENTS.md:90, 205a27a9d70d)
• webhook dispatch lacks timeout payload: dispatchItemReview() sends target repo, branch, item number/kind, source event/action, and supersede state, but no codex_timeout_ms, so item webhooks cannot raise the review timeout from this path. (src/repair/comment-webhook.ts:675, 205a27a9d70d)
• workflow fallback remains fixed: The sweep plan output resolves codex_timeout_ms from client_payload, then workflow input, then the hard default 600000; the review shard passes that value to --codex-timeout-ms. (.github/workflows/sweep.yml:886, 205a27a9d70d)
• media preprocessing consumes pre-Codex runtime: reviewCommand() calls prepareMediaProofArtifacts() before runCodex(), and each video download has curl --max-time 90 followed by ffprobe and ffmpeg contact-sheet generation. (src/clawsweeper.ts:14506, 205a27a9d70d)
• Codex timeout only wraps the Codex process: runCodex() applies options.timeoutMs to the spawnSync('codex', ...) call, so the media-prep time is not included in that per-process timeout even though it is included in the surrounding shard wall-clock budget. (src/clawsweeper.ts:6553, 205a27a9d70d)
• surface stats are available but not wired to timeout sizing: pr-surface-stats.ts aggregates files/additions/deletions and current report rendering uses those stats for review comments; searches found no timeout calculation using them. (src/pr-surface-stats.ts:27, 205a27a9d70d)

Likely related people:

• Dallin Romney: Git blame and git log -S show the initial review workflow, dispatch payload, media-proof preprocessing, PR surface stats, and later failed-review retry timeout handling were introduced or maintained in Dallin Romney commits. (role: introduced behavior and recent adjacent owner; confidence: high; commits: 1aff86c63e59, 40568e1fc23d; files: src/clawsweeper.ts, src/repair/comment-webhook.ts, .github/workflows/sweep.yml)
• Jesse Merhi: git log -S codex_timeout_ms shows Jesse Merhi changed nearby proof-gating Codex timeout paths, making them a secondary routing candidate for timeout/proof interactions. (role: adjacent proof/timeout contributor; confidence: medium; commits: 2af278ebe246; files: src/clawsweeper.ts, .github/workflows/sweep.yml, test/clawsweeper.test.ts)

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.