close_agent can hang indefinitely on previously interrupted subagent, blocking parent thread #31036

Summary

A Codex Desktop parent thread can get stuck indefinitely when calling multi_agent_v1.close_agent on a previously interrupted/nonresponsive subagent. The affected subagent no longer appears to have an OS process, but close_agent remains blocked and the parent thread stays active / inProgress.

I am intentionally not pasting raw transcripts or private workspace paths in this public issue. I can provide logs through a private/support channel if useful.

Environment

• Surface: Codex Desktop on macOS
• Parent thread source: Codex Desktop
• Parent thread id: 019f2670-631e-7fb1-b92e-69c8ca39a356
• Parent thread title: 第一篇论文
• App-bundled Codex version: codex-cli 0.142.5
• Session cli_version: 0.142.5
• Separately installed CLI version on PATH: codex-cli 0.139.0 (likely not involved because the stuck Desktop session reports 0.142.5)
• Multi-agent version: v1

Affected agent

• Subagent id: 019f27b2-5715-7b71-a395-40f1482aff47
• Nickname: Ramanujan
• Role: worker
• Parent thread id: 019f2670-631e-7fb1-b92e-69c8ca39a356

Timeline / observed behavior

All times are from the local session transcript on 2026-07-03.

1. Parent spawned worker subagent Ramanujan:

   • agent id 019f27b2-5715-7b71-a395-40f1482aff47

2. Parent waited for the subagent and timed out repeatedly:

   • wait_agent([Ramanujan], timeout_ms=300000) returned {"status":{},"timed_out":true}
   • wait_agent([Ramanujan], timeout_ms=600000) returned {"status":{},"timed_out":true}

3. Parent attempted to interrupt/redirect the subagent:

   • send_input(target=Ramanujan, interrupt=true, ...) returned a submission_id
   • A following wait_agent([Ramanujan], timeout_ms=120000) again returned {"status":{},"timed_out":true}

4. Parent attempted to close the subagent:

   • close_agent(target=Ramanujan) hung for about 1031 seconds until user abort
   • A later close_agent(target=Ramanujan) hung again for about 602 seconds until user abort

5. In a later heartbeat turn, another short-lived subagent (Kant, id 019f284a-5e20-7712-ae8f-e836d5835aaf) completed successfully and close_agent(Kant) returned immediately with the completed status.

6. The parent then called close_agent(target=Ramanujan) again:

   • transcript last records the function call
   • no function call output follows
   • parent thread remains active / inProgress

Additional local observations

• The child session transcript for Ramanujan exists and shows turn_aborted events.
• The child transcript stopped updating after the earlier aborts.
• A local process search did not reveal a separate OS process corresponding to Ramanujan or its agent id.
• This suggests the stuck state is in Codex Desktop/app-server's logical subagent lifecycle, not in a visible local child process.

Expected behavior

close_agent should be safe/idempotent for a subagent that was interrupted, already aborted, or otherwise nonresponsive. It should not block the parent thread indefinitely.

Ideally it should either:

• return the previous/terminal status,
• mark the agent closed if it has no live worker,
• or return a bounded timeout/error that lets the parent continue.

Actual behavior

close_agent can hang indefinitely on the old interrupted subagent. This blocks the parent thread and prevents the current turn from finishing.

Impact

• Parent thread remains stuck as active / inProgress.
• Automations/heartbeat workflows can be blocked.
• Repeated attempts to close the same agent reproduce the hang.
• The only practical workaround seems to be restarting Codex Desktop/app-server and avoiding future close_agent calls on that old agent.

Workaround used

• Avoid calling close_agent on the stuck agent.
• Use a new focused thread or restart Codex Desktop/app-server to clear the stuck app-server state.
• For future automation prompts, avoid requiring new subagents/agent closing for simple running-lane monitoring.