Custom .codex/agents no longer selectable in CLI v0.137.0; subagents spawn generic and inherit parent model

Resolved 💬 6 comments Opened Jun 4, 2026 by mtsitzer Closed Jun 5, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

6 Comments

dazuiba · 1 month ago

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

kyboi · 1 month ago

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 with fork_turns: "none" and an explicit prompt saying not to spawn agents:

{
  "task_name": "slice_committer",
  "fork_turns": "none",
  "message": "Repo: ...\nStage and commit only: ...\nDo not push. Do not spawn agents."
}

The visible agent tree later showed:

/root
/root/slice_committer
/root/slice_committer/slice_committer

So the committer child spawned a nested committer despite both the explicit prompt and the local slice_committer.toml role 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

etraut-openai contributor · 1 month ago

I've traced this behavioral change to this PR.

winoros · 1 month ago
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?

winoros · 1 month ago

@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/current at the local 0.136.0 standalone release. After that, codex --version reported codex-cli 0.136.0, so the local CLI symlink itself was downgraded.

However, after running:

codex remote-control stop
codex remote-control start

the daemon reported:

Daemon used app-server:
  path: /home/misaka/.codex/packages/standalone/current/codex
  version: 0.137.0

Looking at the app-server daemon path, remote-control start uses the managed install binary at packages/standalone/current/codex, and the daemon bootstrap/updater path can move current back to the latest standalone release. Also, remote-control stop stops 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.0 is not a complete workaround unless they also prevent the managed updater/bootstrap path from re-upgrading current. 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 local 0.136.0 downgrade back to 0.137.0.

winoros · 1 month ago
[features.multi_agent_v2]
enabled = false
hide_spawn_agent_metadata = false

This can work when remote control is enabled.