Windows Desktop 26.803: active turns show no progress for 3–4 hours while the app remains interactive #37775

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.803.41515
Microsoft Store package 26.803.5235.0 (x64)
Bundled app-server 0.147.0-alpha.6.5

What subscription do you have?

ChatGPT sign-in with six-month Codex for Open Source access.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

• Windows 11 Home 25H2, OS build 26200.8875
• Intel Core Ultra 5 235U, 12 cores / 14 logical processors
• 32 GB RAM
• Intel Graphics, driver 32.0.101.8724
• System drive: 475.93 GiB total, 35.20 GiB free

What issue are you seeing?

The most serious symptom is that, on August 9, 2026, several active turns stopped showing any visible reasoning, tool activity, completion, or error for approximately 3–4 hours. The Codex App itself remained interactive, but the affected work appeared to make no progress and did not surface a bounded timeout or recovery state.

Separately, the Windows app became extremely laggy during normal use. Task Manager did not appear to show CPU or RAM exhaustion at the time, and the rest of Windows remained responsive, although I did not capture a time-aligned performance trace.

Sanitized desktop-log analysis from the same day found substantial frontend/app-server state pressure:

• Conversation state not found: 1,891 entries
• item/started for unknown conversation: 4,157 entries
• item/completed for unknown conversation: 4,058 entries
• turn/started for unknown conversation: 532 entries
• app_server_client_request_queue_rejected with reason=queue-expired: 45 entries
• Queue waits were approximately 60 seconds (queueWaitMs=60000–60023) with inFlightRequestCount=2
• Queued background thread/read hydration requests peaked at 36
• Request failed: 73 entries
• Item not found in turn state: 31 entries

The queue-rejection bursts occurred between approximately 12:52 and 17:46 local time (UTC+7). Windows recorded no Codex Application Hang, Application Error, or Windows Error Reporting event on August 9.

These logs show that app-server events continued while the frontend repeatedly failed to resolve conversation state and background hydration requests expired. This is consistent with a UI/app-server synchronization or queue-starvation problem, but it does not prove that a specific turn emitted no backend events for the entire 3–4-hour interval, and I am not claiming a confirmed root cause.

What steps can reproduce the bug?

I do not yet have a deterministic minimal reproduction. The intermittent pattern I observed is:

1. Use Codex Desktop on Windows for normal multi-turn work.
2. Leave active turns running and continue using the app.
3. One or more turns stop producing visible progress while the application shell remains interactive.
4. The affected turns can remain in that state for approximately 3–4 hours without a visible completion, error, or timeout.
5. During the same general period, navigation and interaction across the app become severely laggy.

I have not identified a specific prompt, model, tool, plugin, MCP server, restart condition, or other reliable trigger.

What is the expected behavior?

An accepted turn should continue emitting visible progress or terminate with a clear, bounded error. It should not remain silently active for several hours.

The UI should remain synchronized with app-server turn state, and background thread hydration should not accumulate enough queued work to delay or obscure foreground activity.

Additional information

Potentially related reports:

• #37584 reports progressive lag, stuck turns, and UI/backend desynchronization on the same app/MSIX build. That report also describes memory-leak indicators and eventual silent app exits; in this incident the app remained interactive for hours and Windows recorded no app hang/crash event.
• #36914 reports a blank selected-task pane after restart while collaboration/history hydration saturates the shared request pool. This incident concerns already-active turns showing no visible progress for 3–4 hours on a newer build; the same-day queue expiries were observed with inFlightRequestCount=2, alongside thousands of unknown-conversation lifecycle events.
• #37401 reports app-server queue starvation after opening Plugins. I observed the same queue-expired class, but no deterministic Plugins trigger; the queued work here was primarily background thread hydration.
• #32714 reports a Windows turn remaining active indefinitely after a successful tool result. I have not confirmed the same post-tool trigger.
• #32538 documents multi-hour Windows stalls caused by an auto-review rollout-flush deadlock. I do not have evidence that approval review or rollout flushing caused this occurrence.
• #20214 is the broad Windows freeze/stutter report despite sufficient system resources. The multi-hour silent-turn symptom and sanitized queue/state evidence are the additional details here.
• #32997 reports tasks that appear to keep running while actually stuck, together with duplicate MCP/app children. I have not established an MCP-specific trigger or duplicate-child-process cause.

I can provide targeted redacted desktop-log excerpts and timestamps if maintainers need them. Raw logs are not attached because they contain conversation IDs, local paths, and project context.