Large-context Codex Desktop tasks can remain silent for 9–32 minutes at model response boundaries

Summary

Codex Desktop intermittently remains active but produces no new model events for 9–32 minutes at a response boundary, often after a tool has already completed successfully.

This report intentionally excludes the separate WebSocket reconnect issue. The focus here is the long period with no reasoning, tool call, final response, or visible error after the previous action has completed.

Controlled tests show that post-tool continuation is not universally broken. A ten-tool sequential test completed successfully, with every tool result triggering the next model action within 2.2–5.4 seconds. The stronger common signal in the real incidents is very large accumulated context combined with high or max reasoning.

Environment

• Platform: Windows
• Codex Desktop package: OpenAI.Codex 26.707.9564.0
• Bundled runtime: codex-cli 0.144.2
• Models observed: gpt-5.6-luna, gpt-5.6-sol
• Reasoning efforts observed: high, max
• Zotero MCP: disabled
• WinHTTP proxy: direct
• No HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY variables detected

A separately installed npm CLI was 0.125.0, but it was not used by Desktop.

Controlled baseline

Slow first response

Simple no-tool Desktop prompts took approximately 112–127 seconds to return. A sequential test recorded:

• Total duration: 112.621 seconds
• time_to_first_token_ms: 112414

The bundled CLI also showed a very slow first response:

• Total duration: 154.494 seconds
• time_to_first_token_ms: 153927

Both eventually completed, so these were slow passes rather than permanent hangs. This also suggests that the problem is not limited to the Desktop renderer.

Ten sequential tool continuations

One interactive task executed ten separate PowerShell commands:

Write-Output "STEP_N_OK"

Each command was requested only after the previous result returned.

Results:

• Tools completed: 10/10
• Final response: ALL_10_STEPS_COMPLETED
• Initial time_to_first_token_ms: 112686
• Tool-result-to-next-action delays:

2.328, 2.421, 2.586, 2.700, 5.434,
2.277, 2.713, 2.222, 2.768, 2.949 seconds

• Mean continuation delay: 2.84 seconds
• Minimum: 2.222 seconds
• Maximum: 5.434 seconds

This controlled test did not reproduce a general post-tool continuation failure. Most of its delay occurred before the first model event.

Real-world incidents

Incident 1: SSH verification

An SSH verification tool returned successfully. After the result:

• no new session events for 32 minutes 46 seconds;
• no shell or SSH command remained active;
• no reasoning, tool call, final response, or visible error appeared;
• the task was manually interrupted;
• resuming the same work later completed normally.

Incident 2: completed test suite

A tool completed with 29 passing tests. After the result:

• no new events for approximately 10 minutes 03 seconds;
• the model later resumed and began preparing to wait for a subagent;
• the user interrupted 1.6 seconds after that wait began.

The subagent wait therefore did not cause the preceding ten-minute silent interval.

Incident 3: diagnostic task

A separate diagnostic task reproduced the same behavior after a local apply_patch completed successfully:

• no new events for 9 minutes 17 seconds;
• no subagent wait;
• no long-running command;
• manual interruption required.

This task used:

• Model: gpt-5.6-sol
• Reasoning effort: high
• Input: 114,907 tokens
• Cached input: 110,336 tokens

This indicates that the issue is not limited to gpt-5.6-luna or max reasoning.

Common characteristics

The affected real-world tasks had:

• approximately 115k–132k input tokens;
• high or max reasoning;
• a successfully completed previous tool;
• no active local command during the silent interval;
• no visible model or task events for 9–32 minutes;
• successful completion after restarting or resuming the work elsewhere.

This suggests that large accumulated context may be a stronger common factor than a specific model, tool, or subagent workflow.

Prompt-cache signal

In one incident, cached input changed from approximately 122,624 tokens to 9,984 tokens when the model eventually resumed.

This may indicate extensive context reprocessing or a prompt-cache miss. It does not prove causality, but it may be useful when inspecting backend traces.

Additional log signal

Desktop logs included messages such as:

Received turn/started for unknown conversation

The reported conversation IDs did not always match the newly created canonical task IDs. Some affected tasks still completed, so this message alone does not prove the root cause, but it may indicate a routing or task-registration issue worth checking.

Current interpretation

The controlled ten-tool test shows that the normal lifecycle can work correctly:

model request
→ model event
→ tool call
→ tool result recorded
→ next model request
→ next event or final response
→ turn completed

The real incidents stop somewhere after a completed action, but the available evidence cannot yet determine whether:

1. the next model request was never dispatched;
2. it was dispatched but queued or processed for an unusually long time;
3. large-context reconstruction or cache invalidation delayed it;
4. the response was generated but not routed or persisted;
5. the local task state failed to advance.

A more accurate issue definition is therefore:

Large-context Codex tasks can experience extremely long periods with no model events at a response boundary, including but not limited to boundaries following successful tool results.

Questions for maintainers

1. Which log events confirm that a post-tool model request was actually dispatched?
2. Can backend traces distinguish queueing, context preprocessing, prompt-cache lookup, model execution, and response delivery time?
3. Could the cached-input drop from approximately 122k to 10k indicate a costly context rebuild?
4. What causes Received turn/started for unknown conversation, and can it affect task routing?
5. Is there a watchdog for tasks that remain active but produce no model or tool events for several minutes?
6. Is there a recommended maximum conversation context for long-running Codex Desktop workflows?
7. Can affected task and turn IDs be submitted privately for backend inspection?

Affected task and turn IDs, detailed timestamps, configuration backups, and the full CSV timeline are available privately.