`/subagents` should prioritize user-defined agent names over forced runtime nicknames

Open 💬 1 comment Opened Apr 23, 2026 by zinc1018

Problem

The /subagents UX is confusing in role-based workflows.

When a user intentionally creates agents with business-role names like:

  • Orchestrator
  • Compliance Worker
  • Design Worker
  • QA Evidence Worker

…the UI still surfaces forced Codex-generated runtime nicknames as the visible labels. That makes the feature feel unserious and creates unnecessary confusion in business workflows.

Why this is a problem

  • Users want agent names to reflect actual work roles.
  • Forced random nicknames add noise instead of clarity.
  • The runtime labels are not useful in structured delivery models.
  • The experience is not business-like when the system insists on showing names the user did not choose.
  • /subagents is harder to interpret when it mixes the main session, active workers, and historical/closed entries without clear distinctions.

Expected behavior

If a user names an agent Orchestrator, /subagents should show Orchestrator as the primary label.

Requested improvements

  • Allow explicit user-defined subagent names to be the primary displayed label.
  • Allow hiding or disabling auto-generated runtime nicknames.
  • Clearly distinguish main from spawned workers.
  • Clearly distinguish active, closed, and historical subagents.
  • Support a role-oriented view for teams using structured multi-agent workflows.

Short version

Please let users control subagent display names in /subagents and stop forcing random runtime nicknames into the primary UX. In business workflows, those names are confusing and reduce usability.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗