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

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.