[Follow-up] Multi-Agent V2 needs verifiable full-profile application and lifecycle continuity for custom agents

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.72221

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

This is a follow-up to #32782, not a duplicate of its initial role-selection request.

PR #32749 restores explicit model and reasoning_effort fields for Multi-Agent V2 spawns. Issue #32782 requests restoration of agent_type, or an equivalent configured-profile selector, so a parent can select a registered [agents.<role>] profile.

Those changes address two important launch-time problems:

1. selecting a child model and reasoning effort;
2. selecting a named custom-agent profile.

However, production multi-agent skills also need an end-to-end contract guaranteeing that the selected profile remains fully applied, observable, and stable for the complete child lifecycle.

A successful agent_type call is not sufficient if only the role label is retained while other profile layers are dropped, inherited from the parent, or changed during follow-up turns.

Production use case

I maintain a workflow skill in Codex Desktop with 10 registered Writer profiles:

• 5 profiles use model_reasoning_effort = "max";
• 5 profiles use model_reasoning_effort = "xhigh".

The profiles represent independent roles.

Each profile may carry:

• role-specific developer instructions;
• a configured model;
• configured reasoning effort;
• sandbox configuration;
• role-specific tool permissions or allowlists;
• a stable role identity used by the orchestration workflow.

The workflow depends on the selected profile being applied as one complete configuration unit. Manually passing only model and reasoning_effort cannot replace the profile because the role instructions and permissions are also material.

What #32749 solves

PR #32749 restores model-routing inputs to the Multi-Agent V2 spawn_agent schema:

model
reasoning_effort

This allows a generic child to be launched with an explicit model and reasoning level when using a compatible non-full-history fork.

However, it does not by itself select a registered [agents.<role>] profile.

What #32782 would solve

Issue #32782 requests:

agent_type

or an equivalent named-profile selector.

That would solve the initial selection boundary by allowing the parent to request a registered custom role instead of using task_name as a non-functional role label.

This is necessary and should be implemented.

Remaining contract needed after #32782

After a named profile is selected, Codex should guarantee all of the following.

1. Atomic full-profile application

The effective child configuration should apply the complete selected profile, including:

• developer instructions;
• model;
• reasoning effort;
• sandbox configuration;
• tool permissions and allowlists supported by the profile;
• profile/role identity.

The runtime must not apply only agent_role while silently inheriting the remaining settings from the parent.

2. Explicit precedence rules

Precedence should be deterministic and documented:

1. values explicitly pinned by the selected role should win;
2. when the role leaves a value unset, a valid spawn-time override should survive;
3. otherwise, inheritance from the parent may apply.

Model and reasoning effort should be resolved independently. This is related to #32831.

3. Verifiable spawn receipt and metadata

The parent and user should be able to verify the effective configuration from runtime metadata rather than relying on the child’s self-report.

At minimum, the child record should expose:

agent_role
effective_model
effective_reasoning_effort
effective_sandbox
profile source or scope
parent_thread_id
multi_agent_version

If tool permissions cannot be displayed in full, the metadata should at least indicate that the selected role’s tool policy was applied.

4. No silent fallback

If the requested role is missing, invalid, unavailable, or incompatible with the selected fork mode, spawn_agent should return an explicit error.

It must not silently spawn a generic child with:

agent_role = null

or silently inherit the parent model while preserving a misleading role-like task name.

5. Follow-up continuity

followup_task or any equivalent continuation mechanism must preserve the child’s resolved role, model, reasoning effort, sandbox, developer instructions, and permissions.

A child initially created with one profile must not silently switch to the parent configuration during a later turn.

6. Deterministic lifecycle finalisation

Multi-Agent V2 should provide a documented and auditable way to finalise a completed or failed child.

V1 workflows previously exposed lifecycle operations such as close_agent. If V2 intentionally uses a different lifecycle model, it should provide an equivalent contract that guarantees:

• terminal completion status;
• deterministic resource/slot reclamation;
• abnormal-child reporting;
• no continued turns after finalisation;
• an observable final state for orchestration logs.

interrupt_agent alone is not an obvious equivalent because interruption and final lifecycle closure have different meanings.

7. Desktop and CLI parity

The same profile-selection and lifecycle contract should work through:

• Codex CLI;
• Codex Desktop/app-server;
• fresh sessions using the same supported configuration.

A profile should not work in CLI but silently degrade in Desktop.

Minimal custom-role example

# config.toml

[agents.english_reader]
description = "English reviewer"
config_file = "agents/english-reader.toml"

# agents/english-reader.toml

name = "english_reader"
model = "gpt-5.6-sol"
model_reasoning_effort = "max"
sandbox_mode = "read-only"

developer_instructions = """
Review one assigned novel scope and write the result to the specified
output file. Do not edit other scopes.
"""

Expected spawn shape:

{
  "agent_type": "english_reader",
  "task_name": "review_novel",
  "message": "Review the assigned visible-text snapshot.",
  "fork_turns": "none"
}

Expected result:

• the configured role is selected;
• all effective profile layers are applied;
• the configuration is visible in child metadata;
• follow-up turns retain the same configuration;
• the child reaches a deterministic final lifecycle state.

Why this is distinct from existing reports

• #31814 tracks forced inheritance and missing subagent routing controls.
• #32749 restores model and reasoning_effort exposure.
• #32782 requests the missing custom-agent selector.
• #32831 tracks precedence when a selected role leaves model or reasoning unset.
• #32988 tracks delivery of #32749 to the stable release.

This issue requests the remaining end-to-end contract: complete and verifiable profile application, continuity across later turns, explicit failure instead of silent fallback, and deterministic lifecycle finalisation.

Expected outcome

A production orchestration skill should be able to select a registered custom profile and prove that the same complete profile governed the child from spawn through finalisation.

What steps can reproduce the bug?

1. Register a custom agent profile in C:\Users\<user>\.codex\config.toml:

[agents.english_reader]
description = "English reviewer"
config_file = "agents/english-reader.toml"

1. Create the referenced role configuration:

name = "english_reader"
model = "gpt-5.6-sol"
model_reasoning_effort = "max"
sandbox_mode = "read-only"
developer_instructions = "Review one assigned document scope only."

1. Fully restart Codex Desktop and start a fresh GPT-5.6 Sol / Multi-Agent V2 task.

1. Ask the parent to spawn the registered english_reader role with no inherited history.

1. Inspect the model-visible spawn_agent schema. In the affected session it exposes only:

task_name
message
fork_turns

It does not expose agent_type, profile_id, or another configured-role selector. PR #32749 may add model and reasoning_effort, but it does not add custom-profile selection.

1. Using the profile name as task_name only labels the child task; it does not deterministically select the registered profile.

1. Consequently, the parent cannot prove that the child loaded the profile’s developer instructions, configured reasoning effort, sandbox, and tool permissions.

1. Inspect the available Multi-Agent V2 lifecycle tools. There is no exposed close_agent or clearly documented equivalent that provides deterministic finalisation and an auditable terminal state.

Expected:

• spawn_agent accepts agent_type or profile_id;
• the complete selected profile is applied;
• effective role/model/effort/sandbox metadata is observable;
• continuation turns retain the same configuration;
• completed children have a deterministic final lifecycle state.

Actual:

• the custom profile cannot be selected through the default V2 schema;
• task_name is only a task label;
• full-profile application and lifecycle finalisation cannot be verified.

The current default-session reproduction fails at the initial profile-selection boundary. The continuity and lifecycle requirements above are follow-on acceptance criteria for the end-to-end custom-agent contract once named selection is available; this report does not claim that every post-selection failure was independently reproduced in the same session.

What is the expected behavior?

Selecting a registered custom-agent profile should atomically apply the complete effective profile, including its role instructions, model, reasoning effort, sandbox and supported tool policy. The resolved configuration should remain stable across continuation turns, be observable in runtime metadata, fail explicitly instead of silently falling back, and reach a documented deterministic terminal lifecycle state.

Additional information

_No response_