Custom .codex/agents no longer selectable in CLI v0.137.0; subagents spawn generic and inherit parent model
What version of Codex CLI is running?
0.137.0
What subscription do you have?
Pro Lite
Which model were you using?
gpt-5.5
What platform is your computer?
Linux (WSL2)
What terminal emulator and version are you using (if applicable)?
VSCode
What issue are you seeing?
Summary
In Codex CLI v0.137.0, project-scoped custom subagents under .codex/agents/*.toml are no longer selectable from the model-visible spawn_agent tool surface. Spawned subagents fall back to generic multi_agent_v1 threads, inherit the parent model/reasoning settings, and do not record agent_role or agent_path in session metadata.
This is a regression from earlier CLI versions where spawn_agent accepted an agent_type argument and correctly spawned the configured custom agent.
## Environment
- Codex CLI version:
0.137.0 - Platform: Linux
- Auth mode: ChatGPT
- Parent model:
gpt-5.5 - Custom agents are defined under project scope:
.codex/agents/researcher.toml
## Custom agent shape
Example custom agent file:
```
name = "researcher"
description = "Read-only source researcher."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
nickname_candidates = ["Researcher", "Source Researcher"]
developer_instructions = """
You are a read-only researcher. Do not edit files. Return concise findings.
"""
## Expected behavior
When asking Codex to spawn the custom researcher agent, the spawned thread should:
- Load .codex/agents/researcher.toml
- Use model = "gpt-5.4-mini"
- Use model_reasoning_effort = "medium"
- Record agent_role = "researcher" or equivalent custom-agent identity in session metadata
- Record an agent_path or otherwise show that the custom agent config was loaded
This worked in an earlier Codex CLI version. In that version, the model-visible spawn call accepted an argument like:
{
"agent_type": "researcher",
"message": "...",
"fork_context": false
}
## Actual behavior in v0.137.0
The exposed tool is multi_agent_v1.spawn_agent, and its schema only accepts:
fork_context
items
message
There is no agent_type, agent, name, model, or custom-agent selector field.
When a subagent is spawned with prompt text like “You are acting as researcher,” the spawned session is generic:
source=subagent:thread_spawn
agent_role=None
agent_path=None
model=gpt-5.5
effort=high
multi_agent_version=v1
So the child thread inherits the parent gpt-5.5/high configuration instead of using the custom agent’s pinned gpt-5.4-mini/medium.
### What steps can reproduce the bug?
## Reproduction Steps
1. Create a project-scoped custom agent:
.codex/agents/researcher.toml
with:
name = "researcher"
description = "Read-only researcher."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = "You are a read-only researcher."
2. Start Codex CLI v0.137.0 in that project.
3. Ask Codex to spawn the custom researcher agent.
4. Inspect the available spawn_agent tool schema and the resulting child session metadata.
6 Comments
Not only that, but even the system's built-in agents can no longer be assigned specific models.
For example, if you include a prompt instructing 5.4 mini to explore the codebase, it will still delegate the task to 5.5 instead.
BTW: Downgrade to 0.136 works for me
I’m seeing a related failure mode in v0.137.0.
In a workflow using custom agents under
~/.codex/agents, the parent spawned a committer child withfork_turns: "none"and an explicit prompt saying not to spawn agents:The visible agent tree later showed:
So the committer child spawned a nested committer despite both the explicit prompt and the local
slice_committer.tomlrole saying not to spawn subagents.This lines up with the reported regression: if custom agent role files are not actually loaded and spawned children are generic threads, role-specific instructions, permissions, and metadata-based policy enforcement become unreliable.
The main agent seems to be unable to see the available agent types
I've traced this behavioral change to this PR.
@etraut-openai
It seems that the pr mentioned is
For MAv2 CBv9. I'm not sure what CBv9 is, but MAv2 should be multi-agent v2. I think v1 is intentionally not affected?@etraut-openai one more data point: this is not fully workaroundable by downgrading the CLI binary in environments using the managed standalone + remote-control daemon.
I tried pointing
~/.codex/packages/standalone/currentat the local0.136.0standalone release. After that,codex --versionreportedcodex-cli 0.136.0, so the local CLI symlink itself was downgraded.However, after running:
the daemon reported:
Looking at the app-server daemon path,
remote-control startuses the managed install binary atpackages/standalone/current/codex, and the daemon bootstrap/updater path can movecurrentback to the latest standalone release. Also,remote-control stopstops the app-server process but does not necessarily stop the updater loop.So for users running remote control / app-server daemon, downgrading to
0.136.0is not a complete workaround unless they also prevent the managed updater/bootstrap path from re-upgradingcurrent. The already-running daemon also remains on whatever version it was started with until it is restarted.That makes this regression harder to bypass: v1 custom agent role selection is hidden in
0.137.0, and the managed daemon path can re-upgrade a local0.136.0downgrade back to0.137.0.This can work when remote control is enabled.