`/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:
OrchestratorCompliance WorkerDesign WorkerQA 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.
/subagentsis 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
mainfrom 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗