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

[Q0916]

Summary

Codex Desktop can stall for 90-120 seconds after a tool call has already returned in a long Windows session. The local command itself is fast, but the agent loop does not continue to the next response/action for a long time.

This makes a simple file/report operation appear to take several minutes, even though the filesystem/tool operation completed in under a second.

Environment

• Product: Codex Desktop
• Platform: Windows
• Shell: PowerShell 7 (pwsh)
• Session log CLI version: codex-cli 0.133.0
• Model shown in session context: gpt-5.5
• Session type: long creative-production thread with image-generation history, MCP/tool usage, and large local session history
• Workspace: local Windows filesystem

What happened

In a long active session, I asked Codex to move/copy two generated PNG files into a human-facing report folder.

The underlying local commands were fast:

• A failed PowerShell copy command returned in about 0.6s.
• A later successful copy command returned in about 0.5s.
• The formal report-basket harness commands later completed in roughly 0.03-0.58s each.

However, the agent did not continue promptly after some tool results.

Evidence from local Codex session JSONL

The relevant timing gaps were measured from the local session JSONL timestamps.

Stall 1: after completed local command

• 19:48:51.341: exec_command call emitted for a simple PowerShell file-copy/report operation.
• 19:48:51.937: exec_command result returned with an error. The tool itself completed in about 0.6s.
• 19:50:50.542: user interrupted the turn.

Gap after tool result before interruption: about 118.6s.

During this gap there was no additional tool call. The issue was not filesystem copy latency; the tool result was already available.

Stall 2: after completed MCP/context call

• 19:52:00.971: creative_context call emitted.
• 19:52:01.258: MCP result returned. The MCP call itself completed in about 0.23s.
• 19:53:34.141: next response item / interruption point.

Gap after MCP result: about 92.9s.

Again, the tool/MCP call had already completed. The stall happened between tool-result ingestion and the assistant's next useful action.

Later non-stalled commands

When the correct report-basket harness was used later, the actual commands were fast:

• report harness: about 0.58s
• file listing / mojibake scan / log listing: about 0.03-0.47s

So the observed slowdown was not caused by local file I/O.

Expected behavior

After a tool result returns, Codex should promptly continue with one of:

• summarize the tool result,
• retry/fix the failed command,
• ask the user for a decision,
• or continue to the next planned tool call.

A completed tool result should not lead to a silent 90-120s stall.

Actual behavior

Codex Desktop/agent loop appeared to hang after tool output was available. From the user's perspective, a simple file operation looked like a multi-minute operation even though the command had already completed.

Why this matters

This is painful in production workflows because it makes users misdiagnose the bottleneck as:

• filesystem performance,
• MCP server latency,
• PowerShell latency,
• local harness problems,
• or user workflow mistakes.

The trace suggests the real bottleneck is post-tool-result continuation inside Codex Desktop / the agent loop.

Related observations

Other users have also reported long-session / compaction / heavy-context slowdowns. This may be related to existing reports about Codex Desktop becoming slow in image-heavy or MCP-heavy sessions and context compaction taking a very long time.

Request

Please investigate post-tool-result stalls in long Windows Codex Desktop sessions, especially when the session contains:

• large conversation history,
• image-generation artifacts,
• MCP/tool calls,
• context compaction events,
• and local session JSONL/state files.

It would help a lot if Codex Desktop exposed per-turn timing diagnostics that separate:

1. model reasoning latency,
2. tool execution latency,
3. tool-result ingestion latency,
4. context compaction / hydration latency,
5. renderer/UI latency,
6. local state/sqlite write latency.

That would make it much easier to tell whether a delay is caused by the user's command, MCP, local filesystem, model queueing, or Codex Desktop itself.

[github-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

[Q0916]

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.

[Q0916]

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.

[Q0916]

Closing after adding the additional timing evidence above.