Built-in 60-second update/wait instructions override explicit user requests for infrequent monitoring

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):

1. Start a long-running foreground job in Codex.
2. Explicitly prohibit 60-second polling once the job is stable. Request long monitoring waits and no repetitive unchanged-state updates.
3. Let Codex create an asynchronous wait for the foreground job.
4. While that wait remains pending, observe whether Codex repeatedly resumes the wrapper with yield_time_ms: 60000 and sends “still waiting” commentary.
5. 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.

Start with the built-in developer-instruction excerpts and the observed wait wrapper using yield_time_ms: 60000; the report does not name an implementation file or test. Reproduce with a stable foreground job and an explicit long-interval, quiet-monitoring request. Done means the requested interval and quiet behavior are respected without repeated unchanged-state commentary or wrapper polling.