Repository navigation
Goal and reasoning selectors can show off/high while resumed task remains Ultra and proactive #32596
Description
What version of the Codex App are you using?
Codex/ChatGPT macOS app 26.707.41301 (build 5103).
The related quota incident was first observed after updating to build 5175, but this selector/runtime-state mismatch was reproduced after rolling back to build 5103.
What subscription do you have?
ChatGPT Pro
What platform is your computer?
macOS arm64
What issue are you seeing?
The reasoning and Goal-mode selectors can display a lower/off state while the running task remains on the previous Ultra + proactive multi-agent runtime configuration.
In the observed case:
- A long-running task had Goal mode enabled and was running with Ultra reasoning.
- Ultra was switched down and the app UI indicated that Goal mode was off.
- The task did not actually stop or change runtime modes. It continued working and retained active child agents.
- The app was closed while the UI no longer indicated Ultra.
- After restarting the app, the task resumed/reopened in Ultra mode.
- Changing the selector down again while the goal was running did not affect the in-flight turn.
Sanitized runtime metadata from the active turn still reported:
model = gpt-5.6-sol
effort = ultra
multi_agent_mode = proactive
service_tier = default
This confirms that Fast mode was off, but Ultra reasoning and proactive Goal-mode delegation were still active behind an UI that indicated otherwise.
At one observation point, the affected task still had three active child agents. The active turn ID and start time were unchanged after the selector was moved down, showing that the existing Ultra turn had not been replaced or reconfigured.
This materially amplified usage because the retained Ultra task and its children continued making large-context calls. This issue is related to, but distinct from, the quota/accounting incident in #32591.
No prompts, task names, account identifiers, repository names, local paths, session IDs, or raw logs are included.
What steps can reproduce the bug?
- Start a task with Goal mode enabled and Ultra reasoning.
- Allow it to run long enough to spawn one or more child agents.
- While the goal is still running, change the reasoning selector from Ultra to High and turn Goal mode off.
- Observe that the UI shows the lower/off selection.
- Close and relaunch the app.
- Reopen or resume the task.
- Inspect the active turn/runtime metadata and active children.
Observed result: the task may retain or restore effort=ultra and multi_agent_mode=proactive; changing the selector does not interrupt or reconfigure the active turn, and the UI does not clearly indicate that the old runtime settings remain in force.
What is the expected behavior?
- The selector must accurately reflect the effective settings of the active turn.
- If reasoning or Goal mode cannot be changed during an in-flight turn, the UI should say that the change applies only to the next turn.
- Turning Goal mode off should stop proactive continuation and child-agent creation, or explicitly require/offer interruption of the current turn.
- Closing and reopening the app must not silently restore a stale Ultra/Goal runtime state when the UI was changed before shutdown.
- After restart, any resumed autonomous task should show its actual effective reasoning and delegation settings before it continues consuming quota.
Additional information
The strongest diagnostic signal is the mismatch between visible selector state and persisted turn_context state. This is not merely a delayed visual update: child-agent activity and high-context model calls continued under the retained Ultra/proactive configuration.
Activity
thomast8 commentedon Jul 13, 2026
Corroborating this on macOS Codex desktop on 2026-07-13, with the inverse direction of the same mismatch.
After switching the task to Ultra, the effective developer instructions still included a conservative multi-agent policy equivalent to: do not spawn subagents unless the user explicitly asks. The assistant explicitly cited that higher-priority instruction as the reason it had not delegated.
A side-conversation transition then injected a proactive multi-agent policy stating that the earlier restriction no longer applied. On the following turn, another developer message switched the effective policy back to the conservative version, even though the user expected Ultra to remain active.
This suggests the problem is not only stale selector rendering. The mode-specific developer prompt itself can remain stale or oscillate across turns/conversation boundaries, causing actual agent behavior to contradict the selected mode.
Expected behavior: every new turn after a mode change should contain exactly one effective
multi_agent_modepolicy matching the visible selector; the prior mode prompt should be replaced, and conversation/side-conversation transitions should preserve the selected effective mode rather than re-injecting the default policy.