Allow caller-defined display names for spawned subagents
Summary
Please allow callers to set a stable, user-visible display name when spawning a subagent.
Today, a parent agent can instruct a subagent in the prompt to act under a semantic role name such as Auditor or Librarius, but the platform still assigns an unrelated visible nickname such as Lagrange or Ampere. That makes structured multi-agent workflows harder to audit and explain.
Problem
In structured agent runtimes, subagents often have durable semantic roles, for example:
Auditorfor review workLibrariusfor low-effort context/log/research work- project-specific workbench agents for bounded browser or document checks
The current behavior separates the semantic role in the prompt from the platform-visible nickname. Users then see a name that does not match the role they asked for, and the parent agent has to explain that e.g. Lagrange is actually acting as Auditor.
This affects:
- transparency for users supervising multiple agents
- scanability of agent notifications and audit trails
- role clarity in long-running or governed multi-agent workflows
Observed behavior
A subagent was spawned with an explicit prompt role Auditor.
The tool response returned a platform nickname Lagrange.
The subagent reported that it received the role name Auditor, but could not see the platform nickname and that the dedicated name was only prompt-instructed, not technically set.
Requested capability
Add a caller-controlled display-name field to subagent creation, for example:
{
"agent_type": "explorer",
"model": "gpt-5.4-mini",
"display_name": "Auditor",
"message": "Review the assigned runtime change..."
}
Returned metadata could include both the caller-defined display name and the platform nickname:
{
"agent_id": "...",
"display_name": "Auditor",
"platform_nickname": "Lagrange"
}
If uniqueness is required, Codex could render a combined label such as Auditor (Lagrange).
Acceptance criteria
spawn_agentor the equivalent subagent API supports a caller-provideddisplay_namefield.- The chosen display name is visible in tool results, notifications, and agent status surfaces.
- The spawned subagent can identify its assigned display name without relying only on prompt text.
- Platform-generated nicknames may still exist internally, but they do not replace the caller-defined role name.
- If the requested display name is invalid or unavailable, the API returns a clear validation error or deterministic fallback.
Why this matters
The missing capability does not block delegation, but it reduces transparency, auditability, and user trust in structured subagent workflows where names encode responsibilities.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks for the duplicate suggestions.
I think this issue is related but not a duplicate of #24745 / #24863 / #23588.
Those issues appear to cover rendering bugs where the UI shows raw UUIDs/thread IDs instead of an already available generated nickname or readable label.
This issue asks for a different capability: allowing the caller of
spawn_agentto provide a stable, semanticdisplay_name, such asAuditororLibrarius, and having that name appear in tool results, notifications, and agent status surfaces.So #23588 would improve display of existing nicknames, while this request is about caller-controlled naming as part of the subagent API/metadata contract.
Cross-linking with #23588 after checking current behavior there: I do not think #23588 fully closes this request.
#23588 is about a bug in metadata propagation/rendering: Codex already has some friendly nickname/role metadata for spawned subagents, but some live/replayed UI paths still fall back to the raw UUID/thread id. Fixing #23588 should make existing metadata consistently render as something like
Ampere [architect]instead of019e....This issue asks for a different API capability: the caller should be able to provide a stable semantic display name such as
AuditororLibrariusat spawn time, and have that caller-defined name become part of the subagent metadata contract.So the relationship looks like:
A complete implementation of #26112 would likely depend on the same display surfaces being healthy, so #23588 is a useful prerequisite/foundation. But by itself, #23588 would still leave Codex choosing names like
Ampere/Lagrange; it would not let the caller requestAuditoras the canonical visible label.Minimal
$code-reviewreportReview version/scope:
openai/codexmainfae270932065355b5d7f197b3f1c72912588369b(fae270932065)display_namecapability.$code-reviewusing thecode-review-*slices (breaking-changes,testing,context,change-size).Consolidated findings:
codex-rs/core/src/tools/handlers/multi_agents_spec.rs:557— v1 and v2spawn_agenttool schemas are separate, so addingdisplay_nameto only one surface would either miss acceptance or reject calls on the other surface.codex-rs/core/src/tools/handlers/multi_agents_spec.rs:600— the v2 schema needs its own optionaldisplay_nameproperty and docs; it is not automatically inherited from v1.codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs:190— v2SpawnAgentArgsuses#[serde(deny_unknown_fields)], sodisplay_namewill be rejected until explicitly parsed.codex-rs/core/src/tools/handlers/multi_agents_spec.rs:363— existing tool results exposenickname; do not replace or overload it withdisplay_name, because #26112 asks to preserve both caller-defined display name and platform nickname.codex-rs/core/src/tools/handlers/multi_agents_spec.rs:381— the hidden-metadata result shape currently omits nickname-like metadata. Decide whether caller-provideddisplay_nameis exempt from this privacy/config flag or whether the acceptance criteria need to mention the flag.codex-rs/protocol/src/protocol.rs:2583—SubAgentSource::ThreadSpawncurrently storesagent_nickname/agent_roleonly. A distinct optionaldisplay_namefield is needed so caller display identity does not overwrite platform nickname.codex-rs/app-server-protocol/src/protocol/v2/thread_data.rs:137— app-serverThreadmetadata likewise only carries nickname/role. Add additivedisplayNamewhile preserving existing fields.codex-rs/core/src/agent/registry.rs:221— preferred nickname reservation currently accepts arbitrary strings. Caller-provided display names need validation: trim, reject empty/control/newline values, enforce a small max length, and define duplicate/unavailable behavior.codex-rs/core/src/session_prefix.rs:21— agent names are formatted into model-visible session context. A caller-controlleddisplay_namemust be bounded and safe before being injected.codex-rs/core/src/context/environment_context.rs:584— subagent metadata reaches<environment_context>. Add tests/validation for newline, tag-like, and oversized display names to avoid context injection or unbounded context growth.codex-rs/core/src/tools/handlers/multi_agents_common.rs:137— validation should live at the spawn parsing/control boundary, not only in UI rendering.codex-rs/state/src/model/thread_metadata.rs:74— state DB metadata needs an optional/defaulted display-name field so old records deserialize and new records preserve the value.codex-rs/thread-store/src/types.rs:390— persisted thread metadata stores nickname/role/path only; runtime-only display names would disappear on replay/resume.codex-rs/thread-store/src/types.rs:496— thread metadata patch/update types need display-name support too, or updates will drop the field.codex-rs/core/src/agent/control/spawn.rs:645— resume restores nickname/role only; add display-name restore logic and tests.codex-rs/protocol/src/protocol.rs:3838—CollabAgentSpawnEndEventlacks display-name metadata. Tool output alone is insufficient because notifications/status surfaces also need the caller-defined label.codex-rs/protocol/src/protocol.rs:3911— subagent activity/status events also need display-name propagation or activity rendering will remain path/id-based.codex-rs/app-server-protocol/src/protocol/event_mapping.rs:104— spawn-end event mapping currently builds app-server items without propagating name metadata. Extend the item/state and generated schemas.codex-rs/app-server-protocol/src/protocol/event_mapping.rs:115— receiver state in collab spawn completion is status-focused; it should carry display metadata for canonical app-server consumers.codex-rs/app-server-protocol/src/protocol/v2/item.rs:340—SubAgentActivityitems carry IDs/path but no display metadata. Add display name or a reliable metadata lookup/hydration path.codex-rs/app-server-protocol/src/protocol/v2/item.rs:1052—CollabAgentStateonly hasstatus/message; add optional display metadata for live and replayed collab items.codex-rs/tui/src/multi_agents.rs:84— TUI label formatting currently knows nickname/role/path, not caller display name. Define display priority, e.g.display_namefirst, optional platform nickname second, path/id fallback.codex-rs/tui/src/multi_agents.rs:502— collab transcript rendering can fall back to raw IDs unless display metadata is available in the render path.codex-rs/tui/src/multi_agents.rs:319— v2 activity rendering usesagent_path; it should prefer caller display name and keep path only as fallback/trace metadata.codex-rs/core/tests/suite/subagent_notifications.rs:1030— add end-to-end agent logic coverage where the mocked model callsspawn_agentwith"display_name": "Research Scout"and the child/output/persistence surfaces carry it.codex-rs/core/src/tools/handlers/multi_agents_tests.rs:1043— add a direct handler regression provingSpawnAgentHandlerV2acceptsdisplay_nameand returns/persists the expected metadata.codex-rs/core/src/tools/handlers/multi_agents_spec_tests.rs:40— extend tool-schema contract tests sodisplay_nameexists inproperties, is optional, and has the intended description/output shape.codex-rs/core/src/agent/control_tests.rs:2174— extend resume/persistence tests for display-name restoration alongside nickname/role.codex-rs/core/src/agent/registry.rs:35—AgentMetadatacurrently has onlyagent_nicknameandagent_role; add first-class display identity instead of overloading nickname.codex-rs/core/src/agent/control.rs:493— generated nickname reservation should remain separate from caller display name, because the requested API wants both identities available.codex-rs/thread-store/src/thread_metadata_sync.rs:70— thread metadata sync writes nickname/role/path today; include display name so it survives store updates.codex-rs/core/src/hook_runtime.rs:750— hook context exposes agent id/type but not display name. If spawned agents must identify their assigned display name without relying only on prompt text, this needs a structured, bounded path.codex-rs/core/src/session_prefix.rs:17— session prefix helper should be display-name-aware or replaced with a bounded context fragment for subagent identity.codex-rs/core/src/session/mod.rs:2924— spawned-session environment context needs display-name propagation if self-identification is part of acceptance.Suggested staging:
display_name, distinct from generated nickname, plus tool result shape and core tests.This would be useful for role-based spawned subagents too.
Current behavior assigns opaque/fun names like
Curie,Jason,Hilbert. For workflows with multiple active roles, it is much easier to scan the sidebar if callers can provide a display name, or at least a prefix/suffix, e.g.Comparator2 Epicurus,Fixer1 Banach,Verifier2 Darwin.We can make this work manually by editing local Codex state (
threads.agent_nickname) and restarting the app, but it would be much better as a supported spawn/display option.Before:
<img width="358" height="406" alt="Image" src="https://github.com/user-attachments/assets/0648de0f-5996-43e6-b539-c882dafb6085" />
After:
<img width="386" height="380" alt="Image" src="https://github.com/user-attachments/assets/979e68b1-f83f-4e21-8cf8-d3e1d496aaf5" />
is this coming any time soon. With 10 sub agents spawned each concerning different issues. Time is wasted in remembering context that a particular sub agent was working under