codex - 💡(How to fix) Fix Subagent completion notification shows UUID agent_path instead of nickname in 0.131.0 [2 comments, 2 participants]

What version of Codex is running?

0.131.0

Which model were you using?

Observed in a Codex CLI/API-backed session using spawned subagents. The exact model should not be material to the display issue.

What OS are you running?

Linux

What happened?

After upgrading from 0.130.0 to 0.131.0, spawned subagents no longer consistently display their friendly nickname in later notifications/completion events. The spawn response still includes a nickname, but the completion notification surfaces the UUID-like agent_path instead.

Example from a session:

{"agent_id":"019e42da-a5f5-71e0-b291-9b5a86182c89","nickname":"Aristotle"}

Later notification for the same subagent:

{"agent_path":"019e42da-a5f5-71e0-b291-9b5a86182c89","status":{"completed":"..."}}

In 0.130.0, subagent names were displayed as friendly names in this workflow, e.g. famous scientist/mathematician/author-style names. In 0.131.0, the UI/event surface is exposing the stable ID in places where the nickname was expected.

This looks possibly related to #21870, which changed TUI agent metadata hydration to avoid blocking during agent fan-out. That PR says nickname/role metadata is now filled from ThreadStarted and picker refreshes when available. This symptom looks like a fallback path is rendering agent_path/thread ID even though the nickname is available from spawn metadata.

Steps to reproduce

1. Run Codex CLI 0.131.0.
2. Spawn a subagent.
3. Observe that the spawn result includes both an ID and a friendly nickname.
4. Wait for the subagent to complete.
5. Observe the completion/subagent notification.

Expected behavior

If a subagent nickname is available, subsequent subagent notifications/completion messages should display or include that nickname consistently, with UUID/thread ID as secondary trace metadata at most.

Actual behavior

The later notification displays the UUID-like agent_path instead of the friendly nickname, even though the spawn result included the nickname.

Why this matters

The nickname is much easier to track in multi-agent sessions. Showing raw UUIDs makes subagent status updates harder to scan and appears like a regression from 0.130.0.

Possible cause

This may be a metadata hydration/cache fallback issue introduced by the 0.131.0 TUI/app-server changes, especially #21870. The local receiver-thread cache may not be populated or consulted for the completion notification path, so the renderer falls back to agent_path.

Additional context

This was noticed alongside other 0.131.0 sandbox/TUI behavior changes, but the nickname issue is independent: the subagent itself completed successfully, and the spawn result did include the nickname.