Codex Desktop main thread can stay stuck thinking when a sub-agent remains active

Open 💬 4 comments Opened May 18, 2026 by andrewsohrabi

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.31313 (2867)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

Hardware: Mac with Apple M1 Max.

What issue are you seeing?

Codex Desktop can leave the main thread stuck in an active thinking state when a sub-agent is still active/running, even after the visible work in the main thread has already completed.

Observed behavior from the affected turn:

The main agent was handling a simple local configuration request: append a new section to ~/.codex/AGENTS.md.
Because the sandbox could read but not write that home-directory file, the assistant checked the file and then checked whether the target section already existed.
The visible shell/tool work completed quickly:
ls -l ~/.codex/AGENTS.md && tail -n 20 ~/.codex/AGENTS.md returned successfully.
rg -n "Persistent Codex Agent Rules|Sub-agent Lifecycle|thread count is back to 1" ~/.codex/AGENTS.md returned no matches and exited normally with code 1, which is expected for rg when no match is found.
After that, the main thread still appeared to be stuck on thinking instead of completing or reporting a blocker.
The user observed that a sub-agent was still running/active, and the main thread did not clearly surface that it was waiting on that sub-agent, did not show a clear sub-agent action request, and did not automatically close/terminate the child thread.
The user had to interrupt the turn manually.

After interruption, the thread showed:

<turn_aborted>
The user interrupted the previous turn on purpose. Any running unified exec processes may still be running in the background. If any tools/commands were aborted, they may have partially executed.
</turn_aborted>

This looks like a Desktop app sub-agent lifecycle/status synchronization problem rather than a shell command problem. The visible commands had already returned. The remaining active state appeared to be tied to a child/sub-agent thread still being considered running or not reconciled with the parent thread.

Impact:

The main thread can appear hung even when its visible foreground work is done.
It is not clear to the user whether the parent is still reasoning, waiting on a sub-agent, blocked, or leaking an idle/running child thread.
The user may need to interrupt the parent turn manually, which risks leaving background work in an uncertain state.
Long-running work with sub-agents becomes harder to trust because the app does not clearly show when the thread count/lifecycle has returned to the parent-only state.

What steps can reproduce the bug?

I do not yet have a fully isolated deterministic repro, but the observed repro pattern was:

Open Codex Desktop on macOS using version 26.513.31313 (2867).
Use a local workspace/thread where a sub-agent has been created or is still shown as active/running.
In the main thread, run a simple task that should complete quickly. The observed prompt was a request to append this section to ~/.codex/AGENTS.md:

# Persistent Codex Agent Rules (Sub-agent Lifecycle)

You are the main orchestrator. Follow these rules on EVERY task:

1. Only spawn sub-agents when the task clearly benefits from parallelism or specialization.
2. Always assign each sub-agent a narrow, explicit role + a clear termination condition.
3. After a sub-agent completes its work (or fails), IMMEDIATELY close/terminate the sub-agent thread using an explicit close command. Do not leave any sub-agent in "awaiting instruction", "running", or idle state.
4. Before returning your final answer, confirm that ALL sub-agents have been closed and the thread count is back to 1.
5. If you ever detect a sub-agent that appears stuck, immediately stop it and report the issue.
6. Limit concurrent sub-agents to max 3-4 unless explicitly told otherwise.

Use the /agent command internally when needed to inspect and manage threads.

The main agent determines it cannot write directly to ~/.codex/AGENTS.md from the sandbox, then runs read-only checks like:

ls -l ~/.codex/AGENTS.md && tail -n 20 ~/.codex/AGENTS.md
rg -n "Persistent Codex Agent Rules|Sub-agent Lifecycle|thread count is back to 1" ~/.codex/AGENTS.md

The commands complete. In the observed case, rg returned no matches, which was expected.
Instead of the parent thread returning a final answer or a clear blocker, Codex Desktop continues to show the main thread as thinking.
Inspect the thread/sub-agent state. A sub-agent is still shown as active/running, but the parent thread does not clearly explain that it is waiting on that sub-agent or provide an obvious lifecycle action.
Interrupt the parent turn manually.

Session/token/context details:

Session id was not captured from the UI at the time of the issue.
Token limit/context window usage was not captured.
No long-running shell process was visible in the transcript; the visible shell commands had completed.

What is the expected behavior?

The Desktop app should keep parent-thread and sub-agent lifecycle state synchronized.

Expected behavior when a sub-agent is active:

If the parent is waiting on a sub-agent, the main thread should clearly show that state, including which sub-agent it is waiting on.
If the sub-agent is awaiting user input or review, that should be surfaced clearly in the main thread, not hidden behind a child thread state.
If the sub-agent has completed or failed, the app should reconcile that state so the parent can continue or finish.
If the sub-agent is idle/stuck, the app should provide a clear way to stop/close that sub-agent and unblock the parent.
The main thread should not remain indefinitely in a generic thinking state after all visible foreground tools/commands have completed.
Interrupting the parent should not leave the user uncertain about whether child agents or background work are still active.

A more robust behavior would be a visible parent status such as Waiting on sub-agent: <name> or Sub-agent requires input, plus an explicit inspect/stop action for the child agent.

Additional information

This may be related to, but is more specific than, several existing issues:

#20754: Codex Desktop can remain stuck showing thinking/running even after the task has completed.
#22361: Subagent review requests are not clearly surfaced in the main thread.
#18252: Main-thread subagent list can be inconsistent or lose expand/collapse controls.

The difference in this report is the macOS Desktop App version 26.513.31313 (2867) and the specific observed failure mode where the parent thread stayed in thinking while a sub-agent remained active/running, even though the visible main-thread command sequence had already completed.

If there is a recommended location for collecting Codex Desktop session ids, sub-agent ids, or lifecycle logs on macOS, I can attach those the next time this happens.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#22755
#22361

Powered by Codex Action

Keesan12 · 3 months ago

This is exactly where parent and child lifecycle need different visible states. Thinking is too lossy once subagents exist. The parent should be able to surface something like waiting_on_child, child_requires_input, or child_cleanup_pending instead of flattening all of that into one spinner. Otherwise users interrupt healthy runs because the UI gives them no clue whether the main thread is reasoning, blocked, or just waiting for a child to reconcile. We have been hitting the same boundary in MartinLoop around parent-visible stop reasons.

bySnach · 29 days ago

I am seeing a closely related, but more specific, Windows/current-build variant: all visible subagents are already completed, yet the parent remains stuck until I open one of the completed child tasks.

The same sanitized report was submitted through Codex's private feedback channel without logs or attachments. Tracking ID: no-active-thread-019fb28f-e163-7822-9306-6e6f3cddd4c8.

[Windows Desktop 26.721.4979.0] Parent task stays stuck after subagents finish until a completed subagent is opened

Summary

In the Codex desktop app on Windows 10, the parent task can remain stuck in a waiting/thinking state even though all spawned subagents have already completed successfully. Clicking any completed subagent in the right-hand panel immediately appears to wake or resynchronize the parent task, after which it continues.

This is intermittent, but it happens repeatedly during larger multi-agent projects.

Environment

Codex/ChatGPT desktop package: OpenAI.Codex 26.721.4979.0 (x64)
Package health: Microsoft Store/MSIX status reports Ok
Update status checked on July 30, 2026: no newer package was offered locally
Operating system: Windows 10 Pro 22H2, x64, build 19045.6456
Model/settings when observed: GPT-5.6 Sol, Ultra reasoning, Full access
Workload: large local projects with multiple concurrently spawned subagents

Steps to reproduce

Open a large local project in the Codex desktop app.
Use GPT-5.6 Sol with Ultra reasoning and Full access.
Let the parent agent spawn and coordinate multiple subagents.
Wait until the right-hand panel shows that all subagents have completed.
Observe that the parent task sometimes remains stuck waiting/thinking and does not produce its next update or final response.
Click any already-completed subagent in the right-hand panel.
The parent task immediately resumes or refreshes and continues processing.

Expected result

The parent task should receive and reconcile subagent completion events automatically, without requiring the user to navigate to a completed child task.

Actual result

The subagents complete successfully and are shown as completed, but the parent UI remains stale. Opening a completed subagent appears to trigger conversation hydration, resubscription, or event replay that unblocks the parent.

Sanitized local diagnostic evidence

A read-only local health audit found:

Approximately 15,300 desktop renderer error entries dated July 28–30 containing variants of:
Received item ... for unknown conversation
Received turn started ... for unknown conversation
Received turn completed ... for unknown conversation
Approximately 4,600 of those entries were associated with the primary renderer, including 19 turn/completed events for an unknown conversation.
The current desktop log already contained 183 unknown conversation entries at the time of inspection.
Structured logs contained:
396 dropping message for disconnected connection entries
84 dropping turn-scoped item for unknown turn id entries
2 could not find callback entries
38 observed FINAL_ANSWER deliveries from subagents were logged at informational level, with no corresponding worker failure. This indicates that the workers completed and delivered their results.

These signals are consistent with a renderer/app-server conversation-state synchronization or subscription race: a completion event reaches the desktop process before the target conversation/turn is known to the active renderer, is dropped or not reconciled, and is then recovered when the user opens the completed child task.

Checks that did not indicate a local installation problem

The installed MSIX package is healthy and there is no duplicate current-user Codex installation.
No newer Codex package was offered by the local update source.
The current app build had no Windows Error Reporting crash, application-hang, or crash-dump records.
The local state database passed SQLite quick_check.
All running Codex processes were responding during inspection.
The machine had substantial free RAM and disk space; the behavior did not correlate with local resource exhaustion.
No project files, task histories, state databases, or user-created assets were modified during the audit.

Related reports

#23292 — Codex Desktop main thread can stay stuck thinking when a sub-agent remains active
#9607 — Main agent not receiving subagent completion signal
#16817 — related desktop subagent thread hydration / unknown-conversation behavior

The important additional data point here is that the behavior occurs on Windows 10 with the current installed desktop build 26.721.4979.0, and the child tasks are already visibly completed.

Suggested areas to investigate

Queue and replay turn/item events received before a child conversation is hydrated in the renderer.
Reconcile turn/completed events instead of dropping them when the conversation mapping is temporarily unavailable.
Resubscribe or refresh the parent task when a child completes, rather than only after navigation to the child.
Add telemetry that correlates dropped unknown-conversation events with parent tasks that remain in a waiting state.

Privacy

This report is intentionally sanitized. It contains no project names, file contents, local paths, account details, conversation IDs, turn IDs, or session transcripts. Redacted log excerpts can be collected separately if maintainers need them.

devansh-jain-18 · 15 days ago

Current-build macOS reproduction of the same parent/subagent visibility failure. The user explicitly approved posting this sanitized report publicly.

Environment

Codex Desktop: 26.803.41515 (build 6321)
Codex CLI: 0.147.0
macOS: 26.6.1 (build 25G76)

Observed behavior

A parent task sent a completed implementation to an existing reviewer and entered the collaboration wait path. The last visible parent message said that focused tests and static checks passed and that the current diff was being sent for final review.

The task then appeared frozen on that message for several minutes.

Read-only thread inspection showed that it was not stalled:

the parent turn was active with a collaboration wait in progress;
the reviewer thread was active;
the reviewer had emitted three new progress messages;
the reviewer had found a concrete compatibility failure and was continuing its review.

None of that live reviewer progress was visible in the parent task. The parent view continued to show only its stale pre-wait message, so a healthy review looked like a hung task.

Expected behavior

While the parent is waiting, the main task should show a clear state such as:

Waiting on reviewer: <name>;
the reviewer's latest progress message and timestamp;
whether the reviewer is active, blocked, requires input, or complete;
a direct inspect or stop action.

At minimum, the generic thinking or waiting state should not hide active child progress.

Impact

The stale parent view causes users to assume that the task is stuck, send repeated nudges, or interrupt a healthy review. This is especially confusing in long multi-agent workflows.

This differs from a completed-child reconciliation failure: the child was still active and making coherent progress, but the parent UI did not surface that progress. It is also closely related to #31275, which covers missing subagent activity in the main task list.

This report excludes task IDs, repository names, local paths, source contents, and account data.