[macOS] Long-running task silently changes reasoning effort from High to Low

What version of the Codex App are you using (From “About Codex” dialog)?

Current macOS Codex Desktop app. Exact version details are available privately.

What subscription do you have?

Business workspace. Account details are withheld from this public report.

What platform is your computer?

macOS. Exact build details are available privately.

What issue are you seeing?

An existing, long-running Codex Desktop root task silently changed its saved reasoning effort from High to Light/Low without user input or an agent-issued configuration change.

The local rollout repeatedly recorded High settings. While the same turn was still running, it recorded a thread_settings_applied event with Low. There was no user message at that time. The adjacent records are ordinary reasoning and tool-call events, and the rollout contains no corresponding configuration_update or model-setting tool call.

The already-running turn retained its High turn context when it resumed, but the saved thread setting remained Low. The next two new user turns ran with Low effort. The user noticed the UI showed Light and manually selected High; subsequent settings events and turns returned to High.

This means an explicit user-selected reasoning level did not remain stable, and subsequent work silently ran at a lower effort than requested.

What steps can reproduce the bug?

The exact trigger is not yet known. This sequence was observed once:

1. Open an existing long-running Codex Desktop task at High reasoning effort.
2. Leave a tool-heavy turn running for several hours, including delegated worker activity, resumptions, and compaction.
3. Do not change the root task's model or reasoning effort.
4. Inspect the task later and observe that its saved reasoning effort is Light/Low.
5. Inspect the rollout JSONL and find thread_settings_applied(low) during the active turn without an adjacent user action or configuration update.
6. Send a new message and observe that the new turn runs with effort: low.
7. Manually reselect High and observe subsequent turns return to High.

What is the expected behavior?

• A root task's selected reasoning effort should remain High until the user explicitly changes it.
• Worker/subagent activity, compaction, continuation, or app state synchronization should not mutate the root task's saved reasoning effort.
• If the app intentionally changes reasoning effort, the UI and task history should identify the change and its cause.
• Settings events should record enough provenance to identify whether they came from the user, app synchronization, server state, or an agent configuration update.

Additional information

The local rollout records the setting value but not the actor or source that applied it, so the client trace cannot establish which app/server path initiated the change. Exact version, platform, task, timestamp, and redacted event details can be supplied privately to maintainers.

Related reports:

• #41730 — Windows long-running task silently switches High to unsupported Minimal
• #44152 — Windows root task changes reasoning effort during delegated work

No account email, credentials, private prompts, repository paths, source code, or unredacted rollout contents are included.

No source files or tests are identified in the report. Start by reproducing a long-running macOS task and inspect the rollout JSONL around thread_settings_applied(low), checking for missing configuration_update or user action. Done means the root task stays at High unless explicitly changed, and any intentional change records its source.