codex - 💡(How to fix) Fix Codex Desktop: closed subagents remain selectable/resumable and stale open rows are not closable

Summary

Codex Desktop can leave completed/closed subagents visible or selectable in a way that looks like they are still open. When the user types into the child thread, the UI shows a banner like:

Ask parent to resume sub-agent to continue conversation

From the user's perspective, this looks like the subagent is still hanging around and needs to be closed. From the tool/runtime side, the parent may already have closed the subagent, or the subagent may no longer exist as a live agent handle.

This creates a lifecycle mismatch between:

• the visible Desktop UI / sidebar or child-thread panel,
• the parent-side close_agent result,
• local persisted subagent relationship state, and
• the user's expectation that a finished subagent should be plainly closed and out of the way.

Environment

• Product: Codex Desktop app
• Platform: macOS 26.5, build 25F71
• Codex CLI: codex-cli 0.133.0-alpha.1
• Model surface in use: gpt-5.5
• Multi-agent workflow: parent thread spawned read-only subagents and later closed them from the parent side

What happened

In a Codex Desktop parent thread, several read-only subagents were spawned for short verification tasks. After the tasks completed, the parent called close_agent on the exact returned agent IDs.

Observed states:

1. For the latest completed subagents, close_agent returned a completed previous status, confirming the close path had run.
2. A separate batch was already marked closed in local parent-child relationship state; direct close_agent retries against those exact IDs returned agent ... not found, which appears consistent with no live agent handle remaining.
3. The UI still allowed the user to click into a child/subagent conversation. When the user tried to type into it, the Desktop app showed: Ask parent to resume sub-agent to continue conversation.
4. Older stale subagent rows remained marked open in local persisted relationship state, but close_agent against those exact IDs returned agent ... not found for each one.
5. A supported cleanup/refresh path was not obvious from the UI. A local app-server daemon cleanup route was not available because the control socket was missing in this session.

No private data is included here. Screenshots and local file paths are intentionally omitted because the issue is reproducible from the generic lifecycle behavior.

Expected behavior

One of these should happen:

1. Once a subagent is completed and closed, the Desktop UI should clearly show it as closed and should not present it as an open/active subagent.
2. If the user opens a closed child thread, the composer should be clearly disabled with wording like This subagent is closed rather than prompting for parent resume when the user is trying to get rid of it.
3. close_agent should be idempotent: closing an already-closed or nonexistent subagent should return a clear success-style result such as already closed; no live handle rather than only not found.
4. Persisted parent-child relationship state should not keep old nonexistent subagents marked open if they cannot be resumed or closed.
5. The Desktop UI should provide a visible cleanup/dismiss/detach/clear-stale-subagents action, or automatically reconcile stale open rows after close.

Actual behavior

• Closed subagents can remain visible/selectable enough for the user to try typing into them.
• The UI responds with Ask parent to resume sub-agent to continue conversation, which reads like the subagent still exists and needs a parent action.
• Parent-side close_agent may report completed status for current closed subagents, but may report agent ... not found for older stale entries.
• Local persisted relationship state can still show older child rows as open even though close_agent has no live agent handle for them.
• The user cannot tell whether the child is truly closed, stale, still consuming capacity, or needs a special cleanup route.

Reproduction outline

1. In Codex Desktop, spawn one or more subagents from a parent thread.
2. Let the subagents finish their tasks.
3. From the parent thread, call close_agent using the returned exact IDs.
4. Confirm at least one close returns a completed previous status.
5. Click into the child/subagent thread in the Desktop UI.
6. Try to type a message into the child thread.
7. Observe the banner asking the parent to resume the subagent.
8. Inspect local parent-child relationship state or retry close_agent on older visible/stale child IDs; observe open persisted rows where close_agent returns agent ... not found.

Why this matters

This makes subagent lifecycle hard to trust:

• Users think subagents are still open even after the parent closed them.
• The parent cannot reliably clean up stale rows because close_agent may only report not found.
• The UI language encourages a resume mental model when the desired action is close/dismiss/cleanup.
• Repeated multi-agent workflows become stressful because the user cannot distinguish live work from stale UI state.

Related issues found before filing

This appears related but not identical to:

• #23219: shutdown/nonexistent subagents appearing to count toward spawn limits
• #23296: MultiAgentV2 subagents can acknowledge, time out, or shut down without executing the spawn task
• #23713: Desktop UX for persistent attached agents

This issue is specifically about Desktop close/dismiss/reconcile semantics after subagents have completed or no longer have a live close handle.

Suggested fix direction

• Make close_agent idempotent and explicit for already-closed/nonexistent child IDs.
• Reconcile persisted parent-child state after successful close or not found on a previously known child.
• Add a clear Desktop UI state for closed children.
• Add a user-visible Dismiss closed subagent or Clear stale subagents action.
• Change the child-thread composer/banner wording so closed children do not appear as active work waiting for a parent resume unless resume is truly the intended next action.
• Add diagnostics that show whether a child counts toward any live subagent/session limit.