Codex Desktop stalls 90-120s after completed tool calls in long Windows MCP/image-heavy sessions #24738

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   tool-callsIssues related to tool callingIssues related to tool calling

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   performance

   on May 27, 2026
2. github-actions commented on May 27, 2026

   

   github-actionsbot

   on May 27, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop 26.519 / CLI 0.133.0: long post-tool thinking gaps and excessive context growth even with memories disabled #24336
   • Hang / Application hang/ Stall / Execution stall/Unresponsive UI / UI freeze ————always thinking but no response after "git, find,searchAuto-compacting context" #24434
   • codex-cli stalls for exactly 300s between tool result and next model request (stream disconnected) #23807

   Powered by Codex Action
3. Q0916 commented on May 27, 2026

   

   Q0916

   on May 27, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional context: I’m reporting this with the help of Codex, which extracted the timing evidence from the local session JSONL. I may not be able to answer every implementation-level question, but I can provide additional logs or reproduce the workflow if needed.

   This may overlap with other long-session / context-compaction / MCP performance reports, but I opened it separately because the local timestamps show the stall occurring after tool results had already returned. If maintainers consider this a duplicate, feel free to close or link it; I’m happy to add the timing evidence to the canonical issue instead.
4. Q0916 commented on May 27, 2026

   

   Q0916

   on May 27, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional evidence before closing:

   The same long session later reproduced the post-tool-result stall pattern with longer gaps:

   • 20:01:39.163: Creative Memory context result returned.
   • 20:07:19.867: next response item.
   • Gap after tool result: ~340.7s.

   And again:

   • 20:08:03.919: parallel file-read tool results had all returned.
   • 20:17:54.408: next response item / interruption.
   • Gap after tool results: ~590.5s.

   The underlying local commands still completed quickly. This further suggests the delay is not file I/O, PowerShell, or MCP runtime, but happens after tool-result ingestion and before the agent continues.

   Closing this for now because I may not be able to actively follow up with more diagnostics. The timing evidence above is left here in case it helps future investigation.
5. Q0916 commented on May 27, 2026

   

   Q0916

   on May 27, 2026

   Author

   More actions

   Closing after adding the additional timing evidence above.
6. Q0916

   closed this as completedon May 27, 2026
7. fongryan commented on Aug 26, 2026

   

   fongryan

   on Aug 26, 2026

   More actions

   macOS reproduction with stronger persisted-state evidence (Codex Desktop 26.818.61809, Aug 25–26, 2026).

   Observed:

   • An outer functions.exec orchestration cell awaited nested tools and repeatedly yielded Script running with cell ID ... every ~31 seconds without resolving.
   • This affected unrelated nested backends in the same task: exec_command, workspace dependency discovery, GitHub fetch, web search, and context search.
   • Pure JavaScript inside functions.exec completed immediately, so the isolate itself remained responsive.
   • Changing shell, TTY, login mode, working directory, and repository had no effect. The symptom persisted across Codex and laptop restarts, then recovered after the task was resumed the next day on the same desktop build.

   Persisted local evidence from ~/.codex/thread_history_1.sqlite:

   • Every local command that appeared hung was actually stored as status=completed, exitCode=0, with durationMs=0–1092.
   • Other nested calls were also stored completed: workspace dependency discovery 22 ms, GitHub fetches 868/1166 ms, and context search 1056 ms.
   • Therefore the tools completed successfully; their results were not forwarded back to the enclosing orchestration promise/cell.

   Desktop log evidence:

   • mcp_request_timeout ... pendingCount=5 ... timeoutMs=30000
   • The same request later routed successfully at 31.9 s.
   • Other unrelated task requests showed multi-second queue waits, suggesting request-queue pressure may amplify the lost/delayed completion.

   Cancellation finding:

   1. Start an outer functions.exec cell awaiting nested exec_command("/bin/sleep 15").
   2. Terminate the outer yielded cell after one second.
   3. pgrep still shows both the wrapper and /bin/sleep 15 alive.
   4. Persisted history later records the nested command as completed after 14,868 ms.

   So terminating the outer orchestration cell does not propagate cancellation to the nested tool/process. Repeated terminate-and-retry can leave work behind and may worsen bounded-worker or queue pressure.

   Expected:

   • A completed nested tool result must settle the enclosing functions.exec promise promptly.
   • Terminating the outer cell should cancel or safely detach the nested request and clean up local children.
   • If completion forwarding fails, surface a bounded error instead of leaving the cell pending indefinitely.

   I can provide redacted SQL queries or timestamp extracts if maintainers need them.
8. fongryan commented on Aug 26, 2026

   

   fongryan

   on Aug 26, 2026

   More actions

   One recovery correlation that may help narrow the owning path:

   • The failing and recovered sessions both used Codex Desktop 26.818.61809 and primary runtime bundle 26.819.11345, so recovery was not caused by a runtime-version change.
   • At 2026-08-26T03:24:08Z, the desktop log recorded plugin_uninstall_succeeded pluginId=claude-mem@claude-mem-local.
   • The affected task resumed about three minutes later, and the exact nested-tool pattern began completing normally.
   • The dynamic tool registry dropped from 326 tools during the failure to 312 after recovery; no claude-mem/mcp_search tools remained.
   • The removed plugin had repeatedly reported that its runtime was not set up.

   This is temporal correlation, not proof of causation. I did not reinstall the plugin because deliberately re-wedging the active task would be unsafe. It may be useful to inspect whether plugin uninstall/reconcile rebuilds or clears a completion-dispatch table that can otherwise retain a stale callback/session.
9. fongryan commented on Aug 26, 2026

   

   fongryan

   on Aug 26, 2026

   More actions

   Live deterministic repro in the same macOS task after the earlier comment:

   1. The task was healthy and completed many nested tool calls normally.
   2. A new outer functions.exec cell sequentially awaited /usr/bin/true, workspace dependency discovery, and GitHub fetch.
   3. The cell yielded after 30 seconds and remained pending through an additional 60-second wait and 120-second wait (more than 211 seconds total).
   4. The persisted thread_items row for the first and only reached nested call shows:
      • rollout ordinal: 727
      • command: /bin/zsh -c /usr/bin/true
      • status: completed
      • exit code: 0
      • duration: 0 ms
   5. The later dependency and GitHub calls were never reached because the first await never settled.
   6. After terminating only the outer cell (safe because the persisted child was already complete), a fresh nested exec_command querying SQLite completed in 0.3 seconds.

   This pins the defect to intermittent result forwarding from an already-completed nested tool into its enclosing functions.exec promise/cell. It is not slow shell execution, model continuation latency, or a specific MCP backend.

   It also falsifies the removed claude-mem plugin as the sole cause: the plugin remained absent, the registry contained 312 tools, and the defect still reproduced. Plugin teardown may have temporarily reset the affected state, but it is not a complete fix.
10. fongryan commented on Aug 26, 2026

    

    fongryan

    on Aug 26, 2026

    More actions

    Additional app-level routing evidence from the same desktop session:

    Around 2026-08-26T03:28:16Z–03:28:25Z, the desktop log repeatedly recorded:

    • Received turn/started for unknown conversation
    • Received item/started for unknown conversation
    • Received item/completed for unknown conversation

    Those events referenced another active conversation, not the task used for the live repro, so I am treating them as app-wide correlation rather than claiming they are the exact dropped callback. Still, an item/completed event losing its conversation destination is structurally consistent with the observed nested tool item being persisted as completed while its enclosing functions.exec promise never settles.

    This points maintainers toward the event correlation/routing layer (conversation, turn, item, and nested-tool callback ownership), especially around task resume and concurrent thread restoration, rather than shell execution or an individual MCP server.