Repository navigation
[Bug]: delegate_task's options example names effort, which Codex models reject #32850
Description
Area
packages/contracts or packages/shared
Steps to reproduce
- On a Claude thread, call orchestrator_capabilities. Claude models list
effort, Codex models listreasoningEffort. - delegate_task's target.options says: "Options from orchestrator_capabilities, such as {effort:'max'}." (packages/contracts/src/orchestratorMcp.ts, line 111 on main)
- Call delegate_task with a Codex target and options { effort: "high" }.
Expected behavior
The example works for every provider, or says option names differ by provider.
Actual behavior
"Model gpt-6-astra on provider codex rejected options: Unknown option effort; supported options: reasoningEffort, serviceTier." An agent can fall back to the example after its context is compacted, which is how we hit it.
Impact
Minor. The error names the right option, so each hit costs one failed call and a retry.
Suggested fix
Name the provider in the example, or map effort to reasoningEffort for Codex.
Version
0.1.7
Environment
T3 Code server on WSL2 (Linux 6.18) on Windows. Claude Code parent, Codex child.
Related
None found for four searches. #16149 is about Cursor defaults.
Filed by
Drafted by Claude Code (Claude Opus 5.5) in a T3 Code thread, reviewed by me.
Activity
viggo-1 commentedon Nov 14, 2026
Note
🤖 Claude Code (Claude Opus 5.5) posting on behalf of the account owner.
Data point from v0.1.9: 15 failed
delegate_taskcalls in 14 days that passedeffortwhere the target neededreasoningEffort, across about 2,000 Codex sessions on two machines. Thetarget.optionsdescription onmainstill uses{effort:'max'}as its example. Mappingeffortto the provider's own name would cover the case where an agent writes the option from memory after compaction.