Repository navigation
Description
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
- Set
model_reasoning_effort = "medium"in~/.codex/config.toml. - In T3, start a Codex thread (or a
delegate_taskchild) with gpt-6.1-terra and reasoning efforthigh. - 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
super148666 commentedon Nov 10, 2026
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_updatepresent in every rollout: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/startremoves 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.