codex - 💡(How to fix) Fix Codex Desktop turn lifecycle stalls across image and non-image sessions [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#21360Fetched 2026-05-07 03:41:17
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Timeline (top)
labeled ×6commented ×1

Codex Desktop sessions can get stuck indefinitely showing "thinking" / "generating" after a few turns. This is not limited to long-running sessions: I observed it in small/new image sessions as well as in a long non-image session. Local diagnostics indicate multiple turn lifecycle stall modes:

  • main turn starts but never reaches a normal completion state
  • tool outputs are returned, but the assistant continuation never resumes
  • long non-image sessions enter a core unfinished turn state after compaction/prewarm/interruption activity

The user-visible result is that the session remains in a thinking state and no further assistant message appears.

Error Message

This suggests the main user turn entered Codex core state but did not reach a normal completion/error surface. When Codex cannot continue a turn, it should surface an explicit error, timeout, or cancellation state. A session should not remain indefinitely in a thinking/generating state after:

Root Cause

This is important because it shows the hang is not only image-related. Image inputs appear to increase the chance of stalls, but a non-image long-context session can also hit the failure mode.

RAW_BUFFERClick to expand / collapse

Codex Desktop turn lifecycle stalls across image and non-image sessions

Summary

Codex Desktop sessions can get stuck indefinitely showing "thinking" / "generating" after a few turns. This is not limited to long-running sessions: I observed it in small/new image sessions as well as in a long non-image session. Local diagnostics indicate multiple turn lifecycle stall modes:

  • main turn starts but never reaches a normal completion state
  • tool outputs are returned, but the assistant continuation never resumes
  • long non-image sessions enter a core unfinished turn state after compaction/prewarm/interruption activity

The user-visible result is that the session remains in a thinking state and no further assistant message appears.

Environment

  • Product: Codex Desktop app + Codex CLI
  • CLI version: codex-cli 0.128.0-alpha.1
  • OS: macOS 15.5, arm64
  • Desktop app server observed as: Codex.app ... app-server --analytics-default-enabled
  • Main affected model in real sessions: gpt-5.5
  • Probe model: gpt-5.4-mini
  • GitHub issue report intentionally excludes full transcripts, local private paths, and image files.

Observed cases

Case A: new/small image session, main turn did not complete

  • Session type: image-to-cartoon style task
  • Session size: small/new session
  • Observed diagnostic shape:
    • task_started: 2
    • task_complete: 0
    • user-visible session remained thinking
    • prompt hooks completed normally and did not block
    • later manual abort/interrupt appears in logs

This suggests the main user turn entered Codex core state but did not reach a normal completion/error surface.

Case B: image/pet session, post-tool continuation stalled

  • Session type: image-heavy pet asset generation
  • Observed diagnostic shape:
    • task_started: 8
    • task_complete: 6
    • last successful events include image generation/tool calls and completed shell command outputs
    • final tool outputs appear after the last assistant message
    • no assistant continuation follows the returned tool outputs

This looks like a post-tool continuation failure: tools returned, but the assistant loop did not resume.

Case C: non-image long session, core turn unfinished

  • Session type: assets migration / non-image engineering work
  • Observed diagnostic shape:
    • task_started: 119
    • task_complete: 112
    • context_compacted: 13
    • turn_aborted: 6
    • core logs include session startup prewarm and later interrupt/abort activity

This is important because it shows the hang is not only image-related. Image inputs appear to increase the chance of stalls, but a non-image long-context session can also hit the failure mode.

A/B timing probes

All probes were trivial prompts that completed with OK; the point was to compare turn startup/runtime paths.

Probe pathText promptImage prompt
normal user config/hooks36.49s87.37s
UserPromptSubmit disabled35.49s58.60s
isolated: --ephemeral --ignore-user-config --disable codex_hooks --disable plugins --disable memories --disable tool_search5.76s29.49s
isolated + --disable shell_snapshot5.13s31.37s

Interpretation:

  • UserPromptSubmit hooks do not explain the core issue: text timing is essentially unchanged when they are disabled.
  • Image inputs are a strong latency amplifier even in isolated mode.
  • Normal Desktop/user-config runtime adds a large overhead compared with isolated mode.
  • shell_snapshot is not the main overhead in this probe.

Additional signal: analytics Cloudflare 403 during isolated runs

Even with --ephemeral --ignore-user-config, Codex emitted warnings that analytics events to:

https://chatgpt.com/backend-api/codex/analytics-events/events

failed with Cloudflare-managed 403/challenge HTML.

The probes still completed, so this may not be the sole blocker, but it is a platform-level failing request outside the user's project code/config and may contribute latency/noise or interact badly with retries in Desktop sessions.

Expected behavior

When Codex cannot continue a turn, it should surface an explicit error, timeout, or cancellation state. A session should not remain indefinitely in a thinking/generating state after:

  • the main user turn is accepted
  • tool outputs have already returned
  • compaction/prewarm/interrupt state occurs

Actual behavior

The app can remain indefinitely in a thinking/generating state with no further assistant output. Depending on the case, the rollout/log evidence shows dangling task_started, returned tool outputs without continuation, or unfinished core turns.

Related issues found before filing

  • #20392: dangling task_started hydration issue
  • #19980: "thinking... but no output"
  • #17728: never ending thinking process
  • #14220: hang with parallel long-running tool calls
  • #14251: stuck generating after interrupted turn
  • #16042: compaction-related regression

This report is filed separately because it includes multiple observed stall modes, an image vs non-image split, and A/B evidence that user prompt hooks are unlikely to be the primary cause.

Privacy note

I can provide specific local thread IDs or redacted rollout snippets privately if useful, but I am not posting complete transcripts or user image assets in this public issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When Codex cannot continue a turn, it should surface an explicit error, timeout, or cancellation state. A session should not remain indefinitely in a thinking/generating state after:

  • the main user turn is accepted
  • tool outputs have already returned
  • compaction/prewarm/interrupt state occurs

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING