Agent mindlessly polls long-running work instead of checking progress or advancing independent tasks #41007

Summary

When Codex starts a long-running build or deployment, it can fall into a low-value polling loop: repeatedly re-observing substantially unchanged UI state instead of checking the authoritative progress source and using the wait interval for independent work that is already available.

This is not only a token-efficiency problem. It is an orchestration problem: the agent has enough context to identify useful parallel work, but behaves as though polling is the whole task.

Reproduction

1. Ask Codex Desktop to work through a nested Windows VDI.
2. Have it start a container build or deployment in a web dashboard.
3. Leave other independent work available, such as:
   • inspect the build/deployment status or logs through the most direct available surface;
   • prepare the next code change;
   • inspect repository abstractions;
   • add tests;
   • validate a previously deployed endpoint.
4. Observe Codex repeatedly capture or inspect the same waiting screen.
5. Interrupt Codex and point out that it could check progress or do something else.
6. In the observed case, the container build had already completed by the time of the interruption.

Actual behavior

• Codex repeatedly polls an effectively unchanged surface.
• It does not switch to an authoritative progress source when one is available.
• It does not advance independent queued work during the wait.
• It may miss that the asynchronous operation has already completed.
• User intervention is required to redirect it from waiting to useful work.

Expected behavior

Codex should treat a long-running operation as asynchronous work:

1. Prefer an authoritative, structured progress surface over repeated screenshots of an unchanged page.
2. Choose a sensible/event-driven wait or a long checkpoint interval instead of short model-driven polling.
3. While the operation is pending, execute safe independent work already in scope.
4. Re-check the asynchronous operation after a meaningful event, elapsed checkpoint, or when the independent work finishes.
5. If no useful independent work exists, remain efficiently idle rather than repeatedly reasoning about the same state.
6. Detect and act on completion promptly.

A useful orchestration rule would be:

Before polling again, ask whether the pending operation has an authoritative status source and whether any independent in-scope task can make progress. Poll only if neither path can advance the task.

Why this is distinct from related issues

• Background process polling wastes tokens: each write_stdin poll triggers full API turn with complete history #13733 covers repeated background-process polling and full-history token cost.
• Agents are not managing subagents reliably #40299 covers unreliable subagent management and aggressive waiting.
• [Feature Request] Introduce a status indicator to prevent "Waiting for agents" terminal spam #33485 covers waiting-status UI spam.

This report is narrower: the model fails to schedule useful independent work and fails to switch to the best progress source while a long-running build/deployment is pending.

Environment

• Surface: Codex Desktop
• Host: Windows
• Target: nested Windows VDI
• Workload: container build followed by deployment and endpoint validation
• Observed: 2026-08-26