›_ Codex Issues
Codex Issues / #23971

Codex app: subagent close request triggers "agent loop died unexpectedly" and repeated message submit failures

Open 💬 6 comments Opened May 22, 2026 by omarpinarecords

Summary

While using the Codex desktop app, trying to ask subagents to close caused task creation/message submission to fail repeatedly.

Error shown

Error creating task
failed to start turn: internal error; agent loop died unexpectedly

The thread then showed repeated:

Error submitting message

Trigger / context

  • Action attempted: asked subagents to close / wrap up.
  • Surface: Codex desktop app on macOS.
  • Model/UI state visible in screenshot: 5.5 Extra High, Custom profile.
  • Approximate time: 2026-05-21 around 8:55 PM ET.

Feedback trace

The app uploaded a performance trace and showed this Feedback ID:

0cb0ad3a-6818-4bdc-bf26-8e2ac6ba158e

Expected behavior

The app should either close/stop the subagents cleanly or return a recoverable user-facing error without breaking message submission in the thread.

Actual behavior

The app displayed the internal error agent loop died unexpectedly, and subsequent attempts to submit messages showed Error submitting message repeatedly.

Related issues checked

I found some broadly similar open issues around task creation/app failures, but did not find this exact subagent-close trigger with the uploaded feedback trace ID.

View original on GitHub ↗

6 Comments

omarpinarecords · 1 month ago

Related public sibling: #24389.

GitHub Actions marked #24389 as a possible duplicate of this issue and #23700. It reports multi_agent_v1.close_agent hanging for hours after repeated wait_agent timeouts on an unresponsive subagent, then returning only after user interruption.

That looks like the same close/wrap-up failure family as this issue, even though #23971 surfaced as an agent-loop crash / repeated message-submit failure instead of a long blocking close call. Keeping #23971 open pending maintainer duplicate/canonical decision or upstream fix.

omarpinarecords · 1 month ago

Related public sibling: #24475.\n\nIt reports Codex App/CLI subagent or background-agent tasks triggering repeated reconnect attempts and then stream disconnected before completion, while ordinary single-agent tasks are more likely to complete. The issue also includes app log symptoms around unknown conversation / missing conversation state during subagent launch.\n\nThat looks adjacent to this close/wrap-up failure family because the failure appears when subagent dispatch or lifecycle work begins, even though #24475 surfaces as reconnect/stream disconnect rather than agent loop died unexpectedly. Keeping #23971 open pending maintainer duplicate/canonical decision or upstream fix.

lzy18001500226 · 1 month ago

I am seeing the same error family on Windows Desktop, but with a broader trigger than subagent close: long-lived workspace, many visible threads, large transcripts, context compactions, and cross-thread dispatch. Affected threads can remain readable/listable while new turns or settings updates fail with agent loop died unexpectedly / Error submitting message.

I added the fuller Windows long-session datapoint under #25779 because that issue seems to be the broader meta-bug.

mattboostkit · 1 month ago

Got the same error repeatedly today so it's become unusable. Any news here please team? Pretty important project too...

lzy18001500226 · 1 month ago
Got the same error repeatedly today so it's become unusable. Any news here please team? Pretty important project too...

Same here. Restarting Codex Desktop usually makes it usable again for a while, but having to restart the app over and over during a serious project is really frustrating.

In my case, the thread/workspace may still be readable, but submitting new messages starts failing or becomes extremely slow. After a full restart it recovers temporarily, then the same pattern eventually comes back.

luvisaisa · 27 days ago

Had this same issue today but upon updating just now was fixed ! + didn't trash my "dead" session :) - but weirdly enough this wasn't a subagent but a primary agent problem for me. I would send input to other repos (sibling clones / worktrees) and then the same repo had the issue 3x while the others were fine. Repo / agent session cache issue possibly?