MultiAgentV2 canonical activity items omit effective subagent identity/model/effort metadata #32504

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

ChatGPT Pro

Which model were you using?

Parent: gpt-5.6-sol with ultra reasoning. The reproduced v2 child inherited gpt-5.6-sol / ultra.

What platform is your computer?

Linux 6.17.0-35-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

WezTerm 20240203-110809-5046fc22

Codex doctor report

The full report contains local paths and private topology, so this is the exact relevant subset:

{
  "schemaVersion": 1,
  "codexVersion": "0.144.1",
  "runtime": {
    "platform": "linux-x86_64",
    "installMethod": "npm"
  },
  "config": {
    "model": "gpt-5.6-sol",
    "modelProvider": "openai",
    "multiAgentEnabled": true
  },
  "state": {
    "rolloutDbParity": "ok"
  },
  "terminal": {
    "name": "WezTerm",
    "version": "20240203-110809-5046fc22"
  }
}

codex doctor reported an overall failure only because its network reachability checks were blocked in the managed diagnostic sandbox; that is unrelated to this local schema reproduction.

What issue are you seeing?

The MultiAgentV2 app-server canonical SubAgentActivityItem lifecycle omits resolved child metadata needed by machine-readable telemetry and by any UI that wants to show effective subagent configuration.

The item includes a stable child thread ID, logical agent_path, and lifecycle kind, but it does not include:

• friendly nickname;
• resolved agent role/type, including an explicit default/null;
• effective model provider and model ID after configuration layering;
• effective reasoning effort;
• a bounded human-readable assignment summary (the logical task path is already present).

The child runtime still knows and persists the identity and effective configuration. They are absent from both the v2 spawn result and the parent-facing canonical activity item, so a canonical-v2 consumer must inspect internal child JSONL/SQLite state or poll child threads to recover them.

This is specifically an app-server v2 canonical-output compatibility gap. Deprecated activity events are still fanned out for raw-event and rollout-compatibility consumers, as noted in PR #31299. I am not claiming every v1/raw event was removed. The problem is that the replacement canonical v2 lifecycle does not carry equivalent resolved metadata or document a supported query/migration surface for it.

This has two downstream effects:

1. A telemetry/orchestration layer cannot verify which configured subagent ran, whether the intended model and reasoning level were effective, or attribute usage without scraping internal persistence. Workarounds require brittle polling or extra monitoring workers, wasting tokens and compute.
2. The activity UI cannot render glanceable identity, assignment, model, or effort from the same authoritative parent-visible record. The UI symptom itself is already tracked in Subagents panel no longer shows each agent’s model or reasoning effort #32283; this report is about the underlying supported machine-readable contract.

The implementation gap is visible in merged commit 3d2cb39: the spawn path resolves a nickname immediately before it emits a SubAgentActivityItem, while that item contains only id, agent_thread_id, agent_path, and kind. The app-server then exposes the canonical item lifecycle to v2 clients. A separate v1 canonical item path retains richer receiver metadata, including nickname/role/model/reasoning fields (see #31300).

What steps can reproduce the bug?

1. Run Codex CLI 0.144.1 with MultiAgentV2 active.
2. Make the following collaboration.spawn_agent call. Only the message text is redacted; the structural input is exact:

{
  "task_name": "local_subagent_telemetry",
  "fork_turns": "all",
  "message": "<bounded read-only request to inspect effective child telemetry>"
}

3. Observe the exact spawn result:

{"task_name":"/root/local_subagent_telemetry"}

4. Observe the parent rollout event_msg for the corresponding canonical v2 activity lifecycle (IDs and timestamp redacted):

{
  "type": "sub_agent_activity",
  "event_id": "<redacted>",
  "occurred_at_ms": "<redacted>",
  "agent_thread_id": "<redacted>",
  "agent_path": "/root/local_subagent_telemetry",
  "kind": "started"
}

5. Compare it with the matching child's persisted session_meta and turn_context:

{
  "session_meta": {
    "cli_version": "0.144.1",
    "agent_path": "/root/local_subagent_telemetry",
    "agent_nickname": "Darwin",
    "agent_role": null,
    "model_provider": "openai",
    "multi_agent_version": "v2"
  },
  "turn_context": {
    "model": "gpt-5.6-sol",
    "effort": "ultra"
  }
}

The activity payload cannot identify Darwin or verify openai / gpt-5.6-sol / ultra, even though the matching child snapshot can.

As a same-version control, a v1 configured-role child on CLI 0.144.1 recorded a friendly nickname, role explorer, provider openai, role-specific model, and role-specific effort. This confirms the data is known by the runtime and that the gap is specific to the v2 canonical parent surface rather than unavailable child configuration.

No private prompt, repository path, account identifier, or real thread ID is required to reproduce this.

What is the expected behavior?

MultiAgentV2 should provide one supported, versioned source of effective child lifecycle metadata that app-server clients, the UI, and telemetry consumers can use without internal-state scraping.

At minimum, either the canonical spawn/activity record or a supported thread query should expose:

{
  "schema_version": 2,
  "agent_thread_id": "<id>",
  "agent_path": "/root/local_subagent_telemetry",
  "agent_nickname": "Darwin",
  "agent_role": null,
  "effective_model_provider": "openai",
  "effective_model": "gpt-5.6-sol",
  "effective_reasoning_effort": "ultra",
  "lifecycle_state": "running"
}

The values should reflect the child's effective post-layering configuration, not only requested spawn arguments. A bounded assignment summary and resolution provenance (role, explicit override, inheritance, or fallback) would be useful optional additions.

For compatibility, either map the relevant v1-observable fields into the v2 canonical surface during a documented transition, or publish a versioned replacement schema/query and migration path. The UI should render from that same authoritative record.

Additional information

I searched the issue tracker before filing. These reports overlap but do not cover the canonical app-server telemetry contract:

• Subagents panel no longer shows each agent’s model or reasoning effort #32283 covers the Desktop/Subagents UI omission.
• spawn_agent schema omits supported model and reasoning_effort parameters #32430, [Critical UX regression] multi-agent v2 spawn_agent hides model overrides and rejects the default call shape #32031, and GPT-5.6 Sol cannot specify subagent models, forcing all subagents to also be Sol instances #31814 cover spawn input-schema/model override discoverability and inheritance.
• Add Claude Code-style reusable subagent types to MultiAgentV2 spawn_agent #32418, Custom subagents in .codex/agents are not accessible from tool-backed Codex sessions as docs imply #15250, and Tool-backed Codex Desktop ignores prompt model steering and cannot select named custom agents #32291 primarily cover named reusable-agent selection or prompt steering. Tool-backed Codex Desktop ignores prompt model steering and cannot select named custom agents #32291 also asks the parent to expose resolved type/model/effort, but not a versioned canonical lifecycle schema or migration/compatibility contract.
• Subagent completion notification shows UUID agent_path instead of nickname in 0.131.0 #23588 covers nickname rendering in completion notifications.
• Hooks: distinguish subagent events from main agent #16226 and Full Claude Code Hook Parity (29+) #21753 cover hook identity/parity and broader automation events.
• Parallel-first subagents and nonblocking background task management #22099 covers broader TUI task visibility.

This report is intentionally limited to a supported machine-readable source of effective child metadata on the MultiAgentV2 canonical activity surface. Fixing only the visual label or only the spawn input schema would not restore downstream telemetry compatibility.

Potential implementation direction:

• enrich SubAgentActivityItem, the completed v2 spawn result, or a supported child-thread query with resolved identity and effective config;
• hydrate the record from the final child snapshot after configuration layering;
• preserve the fields through app-server live and replay paths;
• add v1-to-v2 compatibility/migration fixtures and live/replay tests;
• document schema versioning, null/default semantics, and privacy behavior.