[Bug]: Resumed threads send reasoning.effort 'none' to gpt-6.1-sol (unsupported) after restart #26863
Closed as not planned
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- Use a thread with model gpt-6.1-sol with the provider codex
- Have the app restarted by updating, when a thread is running.
- Observe the provider error on resume.
- The same error can appear again on the next continue attempt with different effort levels.
Expected behavior
On resume, T3 should send the user's chosen reasoning effort that gpt-6.1-sol . It should not send none when the model does not support it.
Actual behavior
Provider returns 400 and the turn fails with:
{
"type": "error",
"error": {
"message": "Unsupported value: 'none' is not supported with the 'gpt-6.1-sol' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.",
"type": "invalid_request_error",
"param": "reasoning.effort",
"code": "unsupported_value"
},
"status": 400
}And even if we try to context handoff multiple times to rotate to the same provider and model it still fails.
Impact
Blocks work completely
Version or commit
0.1.4-nightly.20261029.3853
Environment
macOS 26.5.2
Logs or stack traces
Provider Error
{"type":"error","error":{"message":"Unsupported value: 'none' is not supported with the 'gpt-6.1-sol' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.","type":"invalid_request_error","param":"reasoning.effort","code":"unsupported_value"},"status":400}
Screenshots, recordings, or supporting files
Workaround
Context Handoff to a new agent or starting a new thread
Activity
juliusmarminge commentedon Oct 29, 2026
Thanks for the screenshot. I tried to reproduce this on main (f855f01) and couldn't get
'none'sent:thread/start,turn/start, app-server killed mid-turn, thenthread/resumeand new turns on the same thread) with Codex 0.163.0 and with 0.156.1 (the version T3 installs for the built-in ChatGPT provider). On every resumed turn,reasoning.effortwas the effort T3 passed (for examplehigh). When no effort was passed, Codex used the model's default (lowon 0.163) or left the field out (0.156.1, which doesn't listgpt-6.1-sol).gpt-6.1-solwithreasoning.effortleft out works. It returns this exact 400 only when the request literally contains"effort": "none".noneas a reasoning effort. So the value is coming from the thread's saved selection or from Codex's own config.To close the gap, could you share:
codex --version.~/.codex/config.toml, or a Codex profile you use, setsmodel_reasoning_effort, and to what.gpt-6.1-sol.~/.t3/userdata/logs). Please trim anything private.Dipesh-J commentedon Oct 29, 2026
Hi Julius, I checked the local records. Here’s what I found:
Provider: My own Codex CLI at
~/.local/bin/codex. Logs confirm version0.165.0at failure time;codex --versionstill reportscodex-cli 0.165.0.Codex config: An earlier recorded read of
~/.codex/config.tomlconfirms it contained:I found no configured profile or custom Codex home. The config now uses
high, and a fresh Sol test thread succeeds.Thread settings: High was selected for the failed “Continue.” turn. Later attempts with Medium also failed. The available thread history starts with Sol; I found no evidence of an earlier different model.
Sanitized logs — all timestamps are UTC on 2026-10-29:
Your suspicion about the Codex config was supported: it explicitly contained
none. I still couldn’t determine why the effective effort appeared to come from that config despite T3 passinghighfor the turn.A new T3 thread and a separate Codex CLI session both worked afterward. I wouldn’t call this an automatic fix, since the config had also changed. It could be a Codex-side issue involving configuration or resumed-session state, but I haven’t isolated whether the cause is in Codex or T3’s integration.
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Reproduced by driving the Codex app-server directly the way T3 does, not through the T3 app itself. Target was origin/main 6ba3de7 (adapter apps/server/src/orchestration-v2/Adapters/CodexAdapterV2.ts) with codex-cli 0.167.2. Setup: a scratch CODEX_HOME whose config.toml set model_reasoning_effort = "none", which is the reporter's config. A custom HTTP-only Responses provider went through a local logging proxy so each request's reasoning.effort was visible. Steps: initialize with experimentalApi; thread/start with model gpt-6.1-sol and no effort (as codexThreadRuntimeParams sends it); turn/start with effort high and collaborationMode.settings.reasoning_effort high; SIGKILL the app-server mid-turn; start a new app-server; thread/resume; then turn/start 'Continue.' with effort high. Run A (no compaction): thread/start and thread/resume both report reasoningEffort "none", matching the reporter's log. Every request still went out with effort "high" and the resumed turn completed. Run B: same, but thread/compact/start after thread/resume, which T3 sends with no effort. The compaction requests went to gpt-6.1-sol with reasoning.effort "none". Codex retried 5 times, then the turn failed with the reporter's exact error: unsupported_value, 'none' is not supported with the 'gpt-6.1-sol' model, param reasoning.effort. The next turn/start with effort high succeeded. So any thread-level request after resume that does not carry the turn's effort fails, including manual or automatic compaction, which a long resumed thread hits before 'Continue.' proceeds. Scratch, proxy and worktree were removed afterwards.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.