Skip to content

Codex: send the selected reasoning effort in thread/start (mismatch with the Codex default makes terra/luna end turns early) #33823

Open

Description

@super148666

Follow-up to #32488, which was closed as upstream. This one is about a specific change in T3 that avoids the early stops. Background and full data: openai/codex#60133 and the last comments in #32488.

Problem

T3 sends the selected reasoning effort only in turn/start. thread/start carries the model but no effort, so the Codex thread starts with the user's own default (model_reasoning_effort in ~/.codex/config.toml, or the model default if unset).

When the two differ, Codex adds a configuration_update item ({"reasoning":{"effort":"..."}}) to the turn, and gpt-6.1-terra and gpt-6-luna then end the turn after a few tool calls with the task unfinished. The underlying behaviour is a Codex bug, but T3 can avoid triggering it.

Steps to reproduce

  1. Set model_reasoning_effort = "medium" in ~/.codex/config.toml.
  2. In T3, start a Codex thread (or a delegate_task child) with gpt-6.1-terra and reasoning effort high.
  3. Give it a long multi-step task, for example processing 9 input files one at a time and running a check at the end.

The turn ends after 3 to 6 tool calls, in under about a minute, and the final message says the work is incomplete. With effort medium in step 2 the same task completes.

Data

Replays of T3's own thread/start + turn/start against a bare codex app-server (codex-cli 0.167.0, Windows 11, Nov 10). Only the effort placement changes; config.toml default is medium.

Model Effort in thread/start config Effort in turn/start Completed in first turn Seconds
gpt-6.1-terra not sent (config default medium) medium 2/2 221, 236
gpt-6.1-terra not sent (config default medium) high 0/2 40, 63
gpt-6.1-terra model_reasoning_effort: high high 2/2 253, 216
gpt-6.1-terra model_reasoning_effort: high medium 0/2 39, 37
gpt-6-luna not sent (config default medium) high 0/2 76, 45
gpt-6-luna model_reasoning_effort: high high 2/2 508, 496

All 6 failing runs have the configuration_update item in the rollout. None of the 6 passing runs do.

Suggested change

In T3 Code (Nightly) 0.1.9-nightly.20261110.4465, codexThreadRuntimeParams (Codex adapter v2, next to CODEX_THREAD_CONFIG) receives input.modelSelection but forwards only the model:

...input.modelSelection === void 0 ? {} : { model: input.modelSelection.model },
config: {
  ...CODEX_THREAD_CONFIG,
  ...
}

Adding model_reasoning_effort: <selected effort> to that config object when an effort is selected should be enough (rows 3 and 6 above).

Related: when delegate_task is called without an effort, the child ran at low for gpt-6.1-terra while my Codex default was medium, so it hit the same mismatch and stopped after 56 seconds.

I only tested the first turn of a thread. Changing effort in the middle of an existing thread probably still needs the Codex fix.

Workaround

Set the Codex instance's "Launch arguments" to the effort you use:

-c model_reasoning_effort="high"

Tested as codex app-server -c model_reasoning_effort="high" with gpt-6.1-terra and turn effort high, while config.toml still says medium: 2/2 completed (195 s, 227 s), no configuration_update item. One instance covers one effort, so this does not replace the change above.

Environment

T3 Code (Nightly) desktop 0.1.9-nightly.20261110.4465, Windows 11 Pro (10.0.26200), codex-cli 0.167.0.

Activity

  1. super148666 commented on Nov 10, 2026

    @super148666
    Author

    Correction to the issue text, after more runs today. The suggested change still stands, but two things I wrote are too strong, and the steps to reproduce need a caveat.

    It is likely, not certain

    The effort mismatch makes the early stop much more likely, but some mismatched runs do complete. Same replay, same real task, codex-cli 0.167.0, configuration_update present in every rollout:

    Machine Model Ended early Completed
    Windows 11 gpt-6.1-terra 9 1
    Windows 11 gpt-6-luna 2 0
    macOS 27.0.1 (Apple silicon) gpt-6.1-terra 1 3

    So it is not Windows-only. With matching efforts it has never ended early: 11/11 today across both machines, plus 12 earlier runs.

    The steps to reproduce need a heavy task

    A synthetic task of the same shape (9 chunks, about 200 short templated records, a check script at the end) did not reproduce it on my Windows machine: 5/5 completed even with the mismatch. Only my real task does, which has long free-text records, chunks up to 26 KB, and reference documents to read first. If you try the steps with a small generated task, expect it to pass. I think this is why the synthetic runs in #32488 passed.

    I cannot share the real task data. I can share rollouts with the record text removed, or run any build or variant you want against it.

    Why the change is still worth making

    Sending the selected effort in thread/start removes the mismatch for the first turn, and no matched run has ended early on either machine. Details and the feature-flag runs are in openai/codex#60133.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions