Codex Agents V2 in 0.145.0: what changed and how to enable it

Codex 0.145.0 is the first release that makes me want to test Agents V2 seriously. OpenAI now labels the multi_agent_v2 feature flag stable but leaves it disabled by default. Turning it on explicitly forces V2. The release also includes work on concurrency, model selection, roles, and navigation. PR #34383 (opens in a new tab) (відкриється в новій вкладці) spells out the flag behavior. Without that override, Codex can still choose the backend from model metadata. In the tagged catalog, GPT-5.6 Sol and Terra select V2 while Luna selects V1. The tagged model catalog (opens in a new tab) (відкриється в новій вкладці) and the backend-selection implementation (opens in a new tab) (відкриється в новій вкладці) show how the feature override and model preference combine.

The short version

The multi_agent_v2 feature flag is stable and off by default; enabling it forces V2, although model metadata may already select V2.
V2 replaces a flat collection of agent IDs with a navigable task hierarchy.
Context inheritance is explicit, and V2 defines how parent and child mailboxes behave.
0.145.0 includes updates to agent roles, model defaults, cold resume, and TUI navigation.
All agents share one working directory and filesystem instead of isolated worktrees.
max_concurrent_threads_per_session counts spawned-agent threads across the whole session tree.

What changed from V1

V2 gives each branch of work a name and a place in the task tree, then defines how those branches communicate. The tagged V1 and V2 tool definitions (opens in a new tab) (відкриється в новій вкладці) show the difference.

Area	Agents V1	Agents V2
Identity	Opaque agent IDs	Canonical task paths such as `/root/research/api`
Context at spawn	`fork_context` on or off	`fork_turns` accepts `none`, `all`, or a recent-turn count
Communication	`send_input`, targeted waits, resume and close by ID	`send_message`, `followup_task`, mailbox waiting, interruption, and tree listing
Nesting	Governed by `agents.max_depth`	Hierarchical nesting; `max_depth` is ignored
TUI ownership	Spawned V1 threads accept direct input	Parent-owned V2 threads are inspectable but read-only
Configuration	Legacy flat-agent behavior	Per-spawn choices, shared defaults, and durable named roles

The V2 task tree

Every V2 spawn requires a lowercase task_name. Codex resolves it to a canonical path below the spawning agent. A child can spawn another child, and the paths preserve that relationship:

The root can delegate release research, and that agent can pass a focused source audit to its own child. The root can still address either one by its canonical path, while list_agents can narrow the view by path prefix.

Context forking is explicit

V2 replaces the old context boolean with fork_turns. The tagged spawn handler accepts three forms:

V2 spawn context optionstext

fork_turns = "all"   # full history; the default
fork_turns = "none"  # no conversation history
fork_turns = "5"     # the five most recent turns

I can now choose context based on the subtask. A reviewer may need the recent design conversation; a repository explorer may only need a precise assignment. The tagged V2 spawn implementation (opens in a new tab) (відкриється в новій вкладці) shows the exact parser and its default.

Messages and follow-up work are separate

The two message operations do different jobs:

send_message delivers information without starting a new agent turn.
followup_task gives an existing agent more work and triggers a turn when it is idle.

Agents can wait for mailbox updates, be interrupted, or be listed by task path. The tagged collaboration tool schema (opens in a new tab) (відкриється в новій вкладці) defines these semantics.

Roles survive a cold resume

A named role can provide human-facing guidance, a role-specific config layer, and nickname candidates:

~/.codex/config.tomltoml

[agents.researcher]
description = "Audit primary sources and report evidence with links."
config_file = "./agents/researcher.toml"
nickname_candidates = ["Ada", "Grace"]

Relative role files resolve from the config.toml that defines them. In 0.145.0, cold resume also preserves the selected role configuration when a durable V2 agent reloads. The integration test covers role-defined instructions, model, provider, reasoning effort, and permissions. PR #33657 (opens in a new tab) (відкриється в новій вкладці) documents the fix.

Parent-owned V2 child threads are view-only

In the TUI, Codex opens a parent-owned V2 child in view-only mode. I can inspect the thread, while its parent handles communication through the V2 tools. Codex uses that restriction to enforce thread ownership and preserves drafts and queued input while the child is open for inspection. PR #33841 (opens in a new tab) (відкриється в новій вкладці) explains the rationale and tests both writable V1 threads and view-only V2 threads.

How to enable Agents V2

One feature flag is enough to force V2:

~/.codex/config.tomltoml

[features]
multi_agent_v2 = true

The CLI can write the same setting:

Enable Agents V2sh

codex features enable multi_agent_v2

After changing the backend selection, I start a fresh task before testing V2. The removed multi_agent_mode compatibility flag is a no-op in this release, so I leave it unset.

My working configuration

~/.codex/config.tomltoml

[agents]
enabled = true
max_concurrent_threads_per_session = 8
 
[features]
multi_agent_v2 = true

agents.enabled = true is explicit but redundant. The configuration schema says multi-agent tools default to enabled, and an enabled V2 flag takes precedence. I also do not set default_subagent_model or default_subagent_reasoning_effort, so this configuration does not force every spawned agent onto a particular model or effort. Those optional defaults apply only when a spawn does not select a model or reasoning effort. The tagged configuration schema (opens in a new tab) (відкриється в новій вкладці) is the authoritative reference for these fields.

The same schema marks the old max_depth setting as V1-only and says V2 ignores it. I control V2 fan-out with the concurrency ceiling and clear task boundaries instead.

Verify the effective state

I check the installed version and the relevant feature rows together:

Verify Codex and feature statesh

codex --version
codex features list

The relevant output on July 22, 2026 was:

Relevant local outputtext

codex-cli 0.145.0
multi_agent       stable  true
multi_agent_v2    stable  true
multi_agent_mode  removed false

The available tools provide a second runtime check. spawn_agent requires a task_name, and the session exposes tools such as send_message, followup_task, list_agents, and interrupt_agent. The feature list shows the configured flags; the tool surface shows what the active task can use.

High versus Ultra reasoning

Agents V2 works with both High and Ultra reasoning. At High, I explicitly ask Codex to use parallel agents. At Ultra, Codex can delegate proactively, though it may keep a small or tightly coupled task with one agent.

The old multiAgentMode setting is deprecated and ignored. The app-server protocol reference (opens in a new tab) (відкриється в новій вкладці) identifies Ultra reasoning as the source of proactive delegation.

At High, a prompt can be as simple as:

Explicit delegation at Hightext

Use Agents V2 where the work is independent. Delegate source research,
implementation, and verification, then integrate the result in the root task.

Clear task boundaries matter more than whether the concurrency ceiling is six or eight.

The shared-workspace caveat

V2 agents share a workspace instead of getting separate worktrees. The tagged configuration implementation (opens in a new tab) (відкриється в новій вкладці) states that every agent uses the same container, filesystem, and current working directory, and sees edits immediately.

I use Agents V2 to coordinate concurrent work. Task paths, selective context, mailboxes, and durable roles make that work easier to track, but I still have to split it along safe boundaries.

When I enable V2

I enable V2 for broad repository work when several tasks can proceed independently. In 0.145.0, the feature's stable status and the changes to task trees, roles, resume, and navigation give me enough reason to test it seriously. The explicit task tree is the main improvement for me. Choosing how much history each child receives also helps, as does separating information from new work.

I cannot infer speed, cost, or quality improvements from the architecture alone. Those claims need measurements on real tasks. I also do not spawn agents merely to fill eight slots. For a small change, one capable root agent is often the better choice. When research, implementation, tests, and review can proceed independently, V2 gives them a clearer coordination structure.

The minimal setup has been enough for my work so far. When I want to force V2, I turn on the flag, start a fresh task, and check the exposed tools. I raise the concurrency limit only when I can draw clean boundaries between the pieces of work.