›_ Codex Issues
Codex Issues / #34520

Cross-thread message silently changes receiver model and reasoning effort

Open 💬 2 comments Opened Jul 21, 2026 by 406141796-svg
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex Desktop bug: cross-thread message changes receiver model

Summary

When a background Codex task configured as gpt-5.6-terra / medium sends a
delegation/report to a foreground task configured as gpt-5.6-sol / high, the
foreground task is silently changed to gpt-5.6-terra / medium after handling
the incoming report.

This is a cross-thread settings leak. The receiver did not request a model
change.

Environment

  • Surface: Codex Desktop on Windows
  • Codex CLI/app-server version recorded in session metadata: 0.144.0-alpha.4
  • Receiver thread: ******
  • Receiver intended setting: gpt-5.6-sol / high
  • Sender setting: gpt-5.6-terra / medium

Minimal observed sequence

  1. 2026-07-21T10:31:16.492Z: receiver log records

thread_settings_applied with gpt-5.6-sol / high.

  1. 2026-07-21T10:31:16.567Z: receiver accepts an incoming

<codex_delegation> from thread
******.

  1. Receiver completes that turn normally.
  2. 2026-07-21T10:32:29.403Z and 10:32:32.033Z: without a user model

selection, receiver log records thread_settings_applied with
gpt-5.6-terra / medium.

  1. The next turn receives a developer <model_switch> message.

Expected behavior

The destination/background thread may use its own model override. Receiving a
message from that thread must not mutate the foreground/receiver thread's model
or reasoning effort.

Actual behavior

The source thread's terra / medium setting is applied to the receiver.

Relevant product contract

The Codex app-server manual states that optional fields on turn/start
override the model for the target threadId. The send_message_to_thread
tool also says to omit model/thinking to retain the target thread's settings.
Neither contract permits changing the sender or receiver of a separate
cross-thread report.

Reproduction

  1. Open foreground thread A with gpt-5.6-sol / high.
  2. Open background thread B with gpt-5.6-terra / medium.
  3. Send a delegation/report from B to A.
  4. Complete the incoming-report turn in A.
  5. Observe that A changes to gpt-5.6-terra / medium and receives

<model_switch> on the next turn.

Workaround used

  • Do not pass model or thinking in follow-up message tool calls.
  • Stop push-style reports from background tasks to the foreground task.
  • Poll background tasks with read-only thread inspection instead.
  • Manually restore foreground model to gpt-5.6-sol / high after a leak.

Log location (not attached wholesale)

The full local rollout is about 270 MB and may contain project/user content, so
it should not be uploaded unredacted. Relevant event lines are 58738, 58742,
58749, 58750, and 58752 in the receiver rollout JSONL. Attach only a sanitized
excerpt if support requests it.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33418

Powered by Codex Action

grtninja · 1 month ago

Independent corroboration from another Windows 11 Pro / ChatGPT Pro Codex Desktop workflow:

  • a long-running foreground arbiter was intentionally kept on GPT-5.6 Sol Max/Ultra;
  • after cross-task steering/report activity, the receiver silently appeared as GPT-5.5 Medium without an operator model or reasoning change;
  • prompt-level instructions to “preserve the receiver settings” did not make this reliable, which is consistent with an application/app-server transport leak rather than ordinary model behavior;
  • the change materially affected execution quality and usage planning because the task depended on the selected model/effort and the operator did not notice immediately.

The exact sender/receiver rollout excerpt was not preserved before the affected session destabilized, so this is corroboration rather than a new minimal trace. The observed direction differs from the original report (5.6 -> 5.5 rather than sender terra -> receiver), but the invariant is the same: cross-thread activity mutates the receiver’s effective model/reasoning without explicit receiver authorization.

Suggested fail-closed contract: every cross-thread delivery should carry immutable source metadata separately from receiver turn settings; the receiver should log settings_before, settings_after, and settings_mutation_source, and reject any unintended model/effort mutation.