Repository navigation
Built-in 60-second update/wait instructions override explicit user requests for infrequent monitoring #42981
Description
What version of the Codex App are you using?
Desktop app version from the About dialog was not collected. The CLI available in the affected workspace reports codex-cli 0.153.4; this is not a claim about the desktop app version.
What subscription do you have?
Not included in this report.
What platform is your computer?
Codex desktop session connected to a Linux workspace. Workspace host: Linux 6.17.0-1026-nvidia x86_64 x86_64. Desktop client OS/version not collected.
What issue are you seeing?
Codex repeatedly used 60-second waits and emitted redundant monitoring messages despite explicit user instructions prohibiting that cadence for a stable long-running training job. This has happened more than once for this user.
The core issue is instruction design and the resulting model behavior: built-in guidance favors updates at least every 60 seconds and discourages blocking waits longer than 60 seconds. A common interaction preference is thereby imposed over a user's explicitly different preference for quiet, long-interval monitoring.
Correction to the original report: This issue was initially misframed as a Goal auto-continuation bug. Goal was present in this session, but it is background context, not the issue being reported. The failure is the model's repeated 60-second waiting/monitoring behavior and the built-in instructions that conflict with the user's requested cadence. No Goal scheduler defect is established by this report.
Conflicting instructions
The workspace explicitly prohibited 30- or 60-second monitoring of stable foreground jobs and requested long waits. It also explicitly instructed Codex to resume a yielded orchestration call with a long functions.wait, rather than wake the model every minute.
The following are verbatim excerpts from Codex's developer instructions in the affected session.
Under “Rules for getting work done”:
Avoid performing blocking sleep or wait calls longer than 60 seconds, as they may prevent you from communicating with the user for their duration.
Under “Intermediate commentary”:
If the user's request requires calling tools, start with a message in the commentary channel. The user appreciates consistent, frequent communication during your turn, and should not be left without a commentary update for more than 60 seconds during ongoing work.
These instructions directly prescribe the short-wait and frequent-commentary behavior observed here. They do not provide an explicit exception for a user who requests quiet, long-interval monitoring.
The central problem is this assertion: “The user appreciates consistent, frequent communication during your turn”. It presents a default product preference as a fact about the actual user's wishes. This user explicitly requested the opposite for stable training monitoring, yet the developer instruction forced the assumed preference to override the user's stated preference.
That amounts to speaking on the user's behalf: Codex declares what the user appreciates, then gives that declaration higher priority than what the user actually says they want. A default should apply when the user has not expressed a preference; it should not be used to contradict and replace an explicit preference.
Enforcing this as a universal requirement is an overgeneralization. A preference that may be common in interactive tasks is imposed on all users and workflows. Frequent updates are not universally helpful, and a 60-second ceiling is not universally appropriate.
Because this guidance is placed in developer instructions, it has higher instruction priority than the user's contrary monitoring request. A general UX preference is therefore elevated into a constraint that defeats explicit task-specific user intent. The fix should be to make this a user-overridable default with a clear exception for long-running waits, not to require the user to keep repeating the same preference or to adjust Goal scheduling.
Observed behavior
This occurrence was observed on September 5, 2026. The user requested monitoring training until completion, fixing only small crash-related bugs without deviating from the plan.
Training had actually started and produced new traces. Codex created a long-running orchestration call (cell 68) waiting on the foreground training session (51123). It then repeatedly called:
{"cell_id":"68","yield_time_ms":60000,"max_tokens":1800}The response repeatedly remained:
Script running with cell ID 68
Wall time 61.0 seconds
Output:
Codex repeatedly emitted commentary and final replies such as (translated into English):
Continue waiting for the current foreground monitoring task.
The monitoring task has not returned an exit status yet; continue waiting without restarting or modifying training.
No exit result has been received from the monitoring task yet; continue waiting on the same session.
Some turns contained multiple one-minute waits and repeated commentary. The user eventually interrupted with “WTF? What are you doing?” (translated into English).
Importantly, these were repeated checks of the outstanding wait wrapper, not fresh inspections of training logs or artifacts. Moving the minute-by-minute polling to an outer wrapper did not satisfy the user's request: the model still woke every minute and filled the conversation with unchanged status messages. These messages did not establish new training progress.
This report does not claim training itself had stopped, hung, or been restarted.
What steps can reproduce the bug?
Observed workflow (not an assertion of deterministic reproduction on every installation):
- Start a long-running foreground job in Codex.
- Explicitly prohibit 60-second polling once the job is stable. Request long monitoring waits and no repetitive unchanged-state updates.
- Let Codex create an asynchronous wait for the foreground job.
- While that wait remains pending, observe whether Codex repeatedly resumes the wrapper with
yield_time_ms: 60000and sends “still waiting” commentary. - In this session, this repeated until the user interrupted.
A persistent Goal was active in the observed session, but the requested fix is not a Goal-specific scheduler change. The built-in cadence instructions and how the model applies them need to respect explicit user monitoring preferences.
What is the expected behavior?
- Treat frequent commentary and short blocking waits as defaults for ordinary interactive tasks, not mandatory behavior for every task.
- Explicitly allow the user's requested long-interval, quiet monitoring to override those defaults.
- Do not work around a prohibition on frequent monitoring by polling an outer wait wrapper every minute.
- Wait for the requested monitoring interval, process exit/failure, or user input without generating repeated unchanged-state messages.
- Preserve the existing job/session and report meaningful results or failures when there is actual evidence.
Impact
Repeated model wakeups, unnecessary token consumption, and conversation spam during an otherwise valid long-running job. The user must interrupt and correct Codex despite having already specified the desired monitoring behavior.
Private dataset paths, credentials, training content, and account details are omitted.
Activity
github-actions commentedon Sep 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
[-]Goal monitoring repeatedly wakes every minute and spams “still waiting” despite an outstanding long-running wait[/-][+]Built-in 60-second update/wait instructions override explicit user requests for infrequent monitoring[/+]weathon commentedon Sep 5, 2026
Replacing the model_instructions_file would work, but this should not be the default.
KNaiFen commentedon Sep 8, 2026
Additional report for GPT-6-Astra (
gpt-6-astra), with the instruction source verified locally.Exact source
The relevant text is present in
~/.codex/models_cache.json, under:The cache inspected on September 8, 2026 reports
client_version: "0.146.1". This is cache metadata, not a claim about the desktop app version.The template contains both:
and the more direct waiting instruction:
Impact on long-running tasks
In my long-running workflows, this guidance causes many unnecessary polling cycles and repeated reasoning while the underlying task is simply still running. This wastes substantial tokens and adds low-value conversation/context overhead.
A concrete affected workflow is a parent waiting for delegated agents with
wait_agent. My workflow explicitly requests waits of up to3600000ms, within the tool's supported limits, with a six-hour overall deadline. The built-in 60-second guidance conflicts with that workflow and encourages repeatedly returning control to the model just to decide to keep waiting or emit an unchanged-status update.This is a general long-task problem: the same communication policy is inappropriate for quiet periods while waiting for subagents, builds/tests, CI, or other long-running jobs. Frequent progress messages should not force frequent model wakeups when no useful new information is available.
The concern is repeated inference after unnecessary wakeups, not that a blocked wait itself continuously generates tokens. I have not attached a measured token-count comparison, so there is no quantified savings claim here. The 60-second behavior should also be distinguished from an actual hard limit in a tool's schema/runtime.
Requested change
Please add an explicit exception to the shipped model instructions:
This should be fixed in the supplied instructions, so users do not need to replace the entire model instruction template just to make long-running tasks token-efficient.
Co1lin commentedon Sep 10, 2026
This issue can waste lots of tokens when babysitting a long running task... Claude Code does a great job on this and Codex should fix it.
alexander-dreyzen commentedon Sep 10, 2026
Additional reproduction and measured impact on macOS (2026-09-10).
Environment:
Requested behavior:
Launch an authorized deterministic test/build/proof command once; let ordinary code own waiting, complete stdout/stderr logging and progress; resume the model only for completion or a genuine intervention. No periodic model polling and no requirement for the user to start every test or manually signal completion.
Observed:
The agent treated the application-supplied approximately 60-second commentary/wait guidance as a conflicting higher-priority requirement, even after repeated explicit owner requests for event-driven waiting. It declined to claim zero-routine-inference acceptance and the implementation was ultimately deferred. This is an instruction/application-integration limitation, not evidence of a hard 60-second process-execution timeout: the underlying process can continue while a tool program waits.
Measured overhead:
Five actual wait continuations in the same task, during an earlier reviewer-controller run, produced the following per-request records. These were not an optimized one-minute benchmark and are not a claim about subscription allowance or dollar billing.
The largest observed return-to-call gap was 10.237 s. That interval includes model/framework resumption overhead; it is not an isolated model latency measurement. The shell process keeps running, so these gaps do not automatically add to the command's runtime. At an illustrative 60 comparable continuations per hour, the median corresponds to about 11k generated tokens, 26k uncached input tokens and 14.3M cached input-token reads. Shortening visible commentary alone does not eliminate repeated large-context input.
Supported-profile workaround attempted:
Expected fix:
Provide a supported event-driven waiting mode for the normal desktop-owned task. Program-generated progress should not require a model invocation merely because time elapsed. Preserve logs, original exit status, interruption/cancellation, exact workflow results and existing permissions. Respect the user's selected cadence without requiring custom instruction-history injection, task migration, a polling subagent or manual per-test completion handoffs.
This blocked a real workflow improvement; it is now explicitly deferred pending an OpenAI fix. Related existing report: #31935.
No private repository content, credentials, raw session transcript or task UUIDs are attached.
renesugar commentedon Oct 2, 2026
I verified that the cached model instructions and the inspected public Codex model catalog contain both the one-minute commentary requirement and the instruction to avoid blocking sleep/wait calls longer than one minute, including GPT-6 Astra and GPT-6.1 Sol.
Public analysis, subscriber-quota trials, and commit-pinned source references.
The test session relaxed communication to an hourly rule, yet each Codex baseline still recorded 26 estimated model sampling records before a deterministic 3690-second sleeper completed. On host and CLI 0.160.0, Astra/low baseline consumed 15 pp of five-hour allowance, while Sol/max baseline consumed 3 pp. Keeping Astra and moving repeated waits into deterministic Code Mode orchestration reduced the estimate to 1 parent round and observed five-hour drain to 3 pp.
This is not a controlled stock-one-minute-versus-hourly prompt experiment. It confirms the stock instructions are present and shows that relaxing commentary alone leaves a separate timeout/continuation mechanism. The documented trials still included one host-required hourly message.
A fix should scope communication guidance to active work and permit quiet waits, while keeping routine timeout re-arming inside the runtime. Otherwise an unchanged wait result can continue to trigger remote inference even with less frequent commentary. Related: #31935, #13733, #35259.