feat: add --auto-poll default for task command#246
feat: add --auto-poll default for task command#246oitray wants to merge 1 commit intoopenai:mainfrom
Conversation
Foreground task blocks the caller until Codex returns with no client-side timeout cap; in Claude Code a stuck job hangs the parent session indefinitely (observed 11+ min on a small plan review) and can exceed the Bash tool's 10-min ceiling. Adds --auto-poll mode that reuses existing background enqueue + status polling primitives. Default 5-minute cap (overridable via --auto-poll-timeout-ms). On completion: prints stored job result. On timeout: prints "still running, follow up via /codex:status <jobId>" handoff so the parent can keep working. Updates codex-cli-runtime skill and codex-rescue agent docs: - bare task call now appends --auto-poll - --wait opts back to uncapped foreground (original behavior) - --background stays fire-and-forget
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3a096d7bed
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (snapshot.waitTimedOut) { | ||
| const stillRunning = `${queuedPayload.title} still running after ${elapsedSec}s — job ${job.id}. Check /codex:status ${job.id} or /codex:result ${job.id} once it finishes.\n`; | ||
| outputCommandResult( | ||
| { ...queuedPayload, waitTimedOut: true, elapsedSec, timeoutMs }, |
There was a problem hiding this comment.
When --auto-poll times out, the JSON response is built from queuedPayload, which hard-codes status: "queued"; this drops the real state from snapshot and reports queued even after the job has moved to running. Any caller that relies on --json to decide follow-up behavior can make the wrong decision (for example, treating an already-running task as never started). Use snapshot.job.status (and related fields) in the timeout payload instead of the original enqueue payload.
Useful? React with 👍 / 👎.
1 participant
Summary
taskruns foreground by default and blocks the caller until Codex returns, with no client-side timeout cap. In Claude Code that means a stuck job hangs the parent session indefinitely (observed 11+ min on a small plan review). The Bash tool harness can hold for at most 10 min before the call dies and the rescue subagent returns nothing.This PR adds an
--auto-pollmode totaskthat reuses the existing background enqueue + status polling primitives:enqueueBackgroundTaskwaitForSingleJobSnapshot--auto-poll-timeout-ms)result <jobId>would (transparent to the caller)The
codex-cli-runtimeskill andcodex-rescueagent docs are updated to recommend the new defaults:--auto-poll(background + 5-min cap)--wait--backgroundNo new transport code — everything reuses existing helpers (
enqueueBackgroundTask,waitForSingleJobSnapshot,resolveResultJob,readStoredJob,renderStoredJobResult).Test plan
node codex-companion.mjs task --auto-poll --auto-poll-timeout-ms 60000 "Reply READY"returns inline in ~9s with the result block.node codex-companion.mjs task --auto-poll --auto-poll-timeout-ms 1000 "..."returns at ~1.5s with the queued-launch + still-running handoff and a job id.taskwith--waitper agent contract) unchanged.task --background) unchanged.User explicitly authorized opening this PR under their GitHub identity (oitray).
🤖 Generated with Claude Code