Windows Desktop 26.715.4045.0: completed threads remain “thinking”; new messages queue locally and cannot start a turn

What version of the Codex App are you using?

26.715.4045.0 (Microsoft Store/AppX, x64)

The same issue was also reproduced before updating, on 26.715.2305.0.

What subscription do you have?

ChatGPT paid account (exact tier omitted).

What platform is your computer?

Windows, x64, Codex Desktop local-project threads.

What issue are you seeing?

Across multiple unrelated local projects, a thread finishes successfully on the backend but Codex Desktop continues to show “Thinking” and a spinner indefinitely.

This is not only a stale visual indicator. After the stale state appears:

a follow-up message can remain as a local queued-message card instead of creating a new turn;
switching to another thread and back does not recover it;
restarting Codex does not reliably recover it;
Windows Repair and Windows Reset were already tried;
updating from 26.715.2305.0 to 26.715.4045.0 did not fix it;
a thread read reports the last turn as completed with error: null, while the thread itself is idle or notLoaded;
an attempted programmatic follow-up can fail with no active turn to steer, even though the Desktop UI still shows the thread as actively thinking.

The issue occurred repeatedly throughout the day and across unrelated projects, so it does not appear to be caused by one repository, prompt, or workspace.

Representative evidence

Examples observed through the local thread API:

Thread 019e9980-c152-7c82-9286-d870c61e2d87
- backend thread status: notLoaded
- latest turn: completed
- error: null
- Desktop UI still displayed “Thinking”
Thread 019f6a26-ed92-7c82-975c-5a4db657432e
- backend thread status: idle
- latest turn: completed
- error: null
- sidebar/UI continued to indicate activity
Thread 019f74e7-5b61-71b0-b2fd-21fc43e1b609
- backend thread status: idle
- latest turn: completed
- error: null
- UI activity state did not clear reliably
Thread 019f3672-c542-7be2-8858-b4afade51de9
- backend thread status: notLoaded
- latest turn: completed
- a new follow-up remained queued locally
- programmatic follow-up returned no active turn to steer

A control thread that was genuinely running reported active + latest turn inProgress, showing that the backend can distinguish real execution from these stale UI states.

Steps to reproduce

The trigger is frequent but not tied to one exact command:

Open several local project threads in Codex Desktop on Windows.
Run normal multi-step tasks, including tool calls and file work.
Wait until a thread produces its final answer.
Observe that the sidebar spinner and/or central “Thinking” state remains.
Inspect the thread through the local thread API: the latest turn is already completed with no error, and the thread is idle or notLoaded.
Send a follow-up message.
In some affected threads, the follow-up stays in a queued-message card and no new backend turn is created.
Restart, switch threads, or reopen the affected thread; the state may remain broken.

Expected behavior

Once a turn reaches completed, Desktop should clear the thinking/spinner state.
A completed thread should accept a new follow-up and create a new turn.
On startup/recovery, Desktop should reconcile UI state against the backend thread/turn state.
If a queued message cannot start, the UI should show an explicit error and provide a safe retry/recovery action.
A thread must not simultaneously appear active in the UI while the backend reports idle/notLoaded and rejects follow-ups because there is no active turn.

Actual behavior

Completed turns remain visually active.
New input can be trapped in a local queue.
The affected thread may become unusable until a new recovery thread is created.
The bug repeats across projects and survives app update, Repair, Reset, switching threads, and restart.

Troubleshooting already attempted

Waited well beyond normal completion time.
Switched to another thread and back.
Restarted Codex.
Windows app Repair.
Backed up local task records and performed Windows app Reset.
Updated Codex Desktop to 26.715.4045.0.
Avoided repeated Stop/Send actions.
Verified backend status using thread list/read APIs.

None provided a durable fix.

Impact

This makes the Desktop execution state unreliable and can block continuation of completed project work. Users cannot tell whether a task is genuinely active, completed, or disconnected, and may accidentally duplicate work or create fragmented recovery threads.

Related issues

VS Code extension crash can leave a thread permanently stuck in "thinking" with queued input #14127 — permanently stuck “thinking” with queued input
Desktop: "Error submitting message" — turn/start times out (30s) while app-server sidecar stalls silently for minutes #27395 — turn/start/sidecar stall and missing turn completion
Desktop app hides task interruption/stall, making an inactive Codex run appear to still be working #32948 — inactive Desktop runs appearing to still be working

The distinguishing detail here is cross-project recurrence on Windows Desktop 26.715.4045.0 with direct evidence that the latest turns are already completed while the UI remains thinking, plus follow-up rejection/queueing.

Screenshots showing the stale “Thinking” state and queued message cards are available if maintainers request them.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Desktop app hides task interruption/stall, making an inactive Codex run appear to still be working #32948
Windows: Codex can remain active with no progress after tool or stream boundaries #33090

Powered by Codex Action

I can reproduce this on Windows x64 with Codex Desktop 26.715.7063.0, so the issue is still present in a build newer than 26.715.4045.0.

Reproduction:

Let a normal turn finish successfully.
Leave the thread idle for a few minutes without sending anything.
Return to the same thread and submit a follow-up in the default Steer mode.
Desktop shows: Error creating task: no active turn to steer.

The local lifecycle evidence shows the previous turn had already completed with error: null, followed several minutes later by Shutting down Codex instance and Agent loop exited. The backend/thread is completed and unloaded, while Desktop appears to retain stale active-turn state and routes the next message through turn/steer instead of starting a new turn.

Recovery currently requires restarting Desktop or continuing in a new thread. Changing the default to Queue is not sufficient because both Steer and Queue are needed, and queued follow-ups can also remain stuck.

Expected recovery:

reconcile renderer state with backend state when resuming the thread;
clear stale active-turn/streaming state after turn/completed;
on NoActiveTurn or ExpectedTurnMismatch, retry exactly once as turn/start, preserving the client message ID;
drain queued follow-ups from a host/app-server lifecycle event rather than renderer focus.

No local paths, task content, or credentials are included.

Additional macOS reproduction and source-isolation evidence, submitted by the diagnosing Codex agent with the account owner’s explicit authorization.

Environment

Codex Desktop for macOS (Apple Silicon): 26.721.41059, bundle 5848
Bundled Codex CLI/app-server: 0.145.0

Reproduced lifecycle

The affected thread was authoritative idle with its latest turn completed, while Desktop still rendered Thinking, a stop control, and a paused Goal. Repeated follow-up attempts were sent as turn/steer and failed with:

code: -32600
message: no active turn to steer
error name in renderer: Error

The conversation/session remained intact and readable. This was not session corruption.

Build-specific renderer source isolation

In this signed build’s renderer entry, the send-follow-up-message path already implements the intended recovery shape:

try steering the current turn;
catch an inactive-steer error;
start a new turn as fallback.

However, the catch predicate recognizes only the renderer’s internal SteerTurnInactiveError name/string. The app-server rejection arrives as a generic Error whose message is exactly no active turn to steer, so the predicate returns false and rethrows. The already-implemented turn/start fallback is therefore skipped, producing the red failed-message state.

Public app-server source seam

Current public source exposes the other half of the mismatch:

turn_processor.rs maps SteerInputError::NoActiveTurn to "no active turn to steer" with data = None.
The adjacent ActiveTurnNotSteerable branch already serializes structured TurnError data with a specific CodexErrorInfo variant.
core/src/session/mod.rs currently reduces NoActiveTurn to generic CodexErrorInfo::BadRequest for its error event.

A durable cross-client contract would add a typed NoActiveTurnToSteer (or equivalent) CodexErrorInfo/JSON-RPC data discriminator and cover it in app-server protocol tests. Desktop should branch on that structured discriminator when available, while retaining the exact-message compatibility check for older app-server builds.

Changing the public app-server alone will not repair already-shipped Desktop renderers if their JSON-RPC Error wrapper discards or ignores data; the Desktop source-owner change is still required.

Narrow Desktop correction

classify structured NoActiveTurnToSteer when available;
for compatibility, classify the exact normalized backend message no active turn to steer as inactive;
do not classify every -32600 invalid request as inactive;
when authoritative thread/latest-turn state is idle/completed, clear stale Thinking/stop state and choose turn/start before attempting steer.

Suggested regression cases:

structured NoActiveTurnToSteer -> inactive (true)
internal SteerTurnInactiveError -> inactive (true)
generic Error("no active turn to steer") from an older server -> inactive (true)
unrelated -32600 invalid request -> inactive (false)
arbitrary network/permission error -> inactive (false)

Recovery control

After the user explicitly resumed the paused Goal, Desktop created a real in-progress turn. Retrying the same failed message then succeeded as turn/steer (errorCode=null) and the user message appeared inside that same turn after agent commentary; the agent continued processing it. A brief read showing an in-progress turn with zero items was the normal interval between Goal resume and the first streamed item, not a ghost turn.

So Resume + Retry is a verified immediate recovery, but it does not remove the stale-idle classifier defect in the signed build. No signed bundle was modified, and no source merge or production rollout is being claimed.

Additional macOS Codex Desktop reproduction (2026-08-14):

Before restarting Codex, thread 019fa4ea-80fe-79b3-afc0-689bb52f12ba is responsive, while thread 019fc246-0b10-75e2-acfe-d666c96cd246 is not responding. This is thread-specific within the same running app rather than a general connectivity failure. Codex has not yet been restarted, so recovery has not yet been tested.

Additional reproduction on current Windows build `26.814.5517.0`

Observed on 2026-08-20 JST.

Environment:

Windows 11 Pro, 10.0.26200, x64
Microsoft Store package: OpenAI.Codex 26.814.5517.0
Desktop app-server log client version: 26.814.41957
Local project threads

User-visible behavior:

Several unrelated completed tasks show the square Stop control as if they were still running.
A follow-up prompt may not appear or start immediately, then can appear and complete later.
Restarting after the app update did not clear the stale state.
Forking an affected task restored usability; the original task remained stale.

Read-only backend verification:

Three affected original tasks reported idle or notLoaded.
Their latest turns were completed with error: null.
A genuinely running control task reported active with an inProgress turn, so the backend still distinguishes real execution from the stale Desktop state.
state_5.sqlite and logs_2.sqlite both passed read-only PRAGMA quick_check.

A related archive failure occurred in the same Desktop run:

A completed task remained archived=0 with archived_at=null after the Archive action failed, including after restart.
Its rollout JSONL still existed under the active sessions store.
The stored rollout path used the Windows verbatim \\?\ prefix.
The archive request reached the app-server and tore down an idle listener, but the archive state did not persist.

That archive evidence matches #39209 / #39130. I am not claiming that the stale Stop/queued-prompt behavior and the archive path bug necessarily have one root cause, only that they co-occurred on the same current build.

Expected behavior:

Completed turns should reconcile the composer to Send instead of Stop.
Follow-up prompts should create a visible backend turn immediately or show an explicit error.
Restart/resume should reconcile renderer state with idle / notLoaded backend state.
A failed archive should not leave the task in a partially torn-down or misleading UI state.

No session database, rollout JSONL, project file, or Desktop state was modified during diagnosis. Private paths, task IDs, and conversation contents are intentionally omitted.

Additional sanitized aggregate evidence on Windows Desktop 26.814.5517.0 (submitted with the account owner's authorization):

I independently observed the same “Thinking with no rendered text/progress” class of failure. Over two days, aggregate-only local application-log counts were:

Signal	Count
`ResizeObserver ... undelivered notifications`	3,136
`turn/started for unknown conversation`	334
`Timed out waiting for structured result`	233
app-server socket `EPIPE`	16

An interrupt also returned no active turn to interrupt while the desktop client was still attempting to resume the affected conversation. This is consistent with stale renderer active-turn state, unbound turn events, renderer update failures, and/or loss of the local app-server stream.

No raw logs, prompts, account information, project content, local paths, session/thread IDs, request IDs, or credentials are included.

Suggested recovery behavior: reconcile renderer state with authoritative thread/turn state after reconnect or resume; surface a bounded actionable error if a turn cannot bind to a known conversation; and clear stale Stop/Thinking state when no active turn exists.

[Windows][26.814.5517.0] UI remains "Thinking" after backend turn completes

Summary

Codex Desktop on Windows can remain indefinitely in the Thinking state after the backend turn has already completed. The final response is persisted but does not appear in the live conversation view. Force-closing and reopening the app makes the completed response visible.

This reproduction occurred on Microsoft Store/AppX package OpenAI.Codex_26.814.5517.0_x64__2p2nqsd0c76g0.

Environment

Codex package version: 26.814.5517.0
Package status: Ok
Package architecture: x64
Package family: OpenAI.Codex_2p2nqsd0c76g0
OS values reported by Get-ComputerInfo: WindowsProductName=Windows 10 Home, OsBuildNumber=26200, OsArchitecture=64-bit
Installation: Microsoft Store/AppX
Primary Codex process at capture: Responding=True, working set approximately 327.6 MB
Windows Application log: no matching Application Hang, Application Error, or Windows Error Reporting event for Codex during the captured session

The raw Windows product label and build number are reported without reinterpretation because the product label can lag the actual Windows build family.

Actual behavior

A normal turn finishes on the backend.
Codex Desktop continues to show Thinking and does not display the final response.
A follow-up/steer attempt is rejected with no active turn to steer, proving the backend no longer considers the turn active.
Force-closing and reopening Codex makes the already-completed response visible.

The app remains responsive at the Windows process level; this is a live renderer/thread-state synchronization failure rather than a model still reasoning.

Expected behavior

When the backend turn completes, Desktop should apply the completion event, clear Thinking, render the final response, and allow the next message without requiring an application restart.

Reproduction

The failure is recurrent but not deterministic:

Launch Codex Desktop on Windows.
Open an existing local-project conversation.
Send a normal request and wait for completion.
Observe that the app remains on Thinking after the response should have completed.
Attempt a follow-up or steer action.
Observe no active turn to steer in the Desktop log while the UI still appears active.
Force-close and reopen Codex.
Observe that the final response is now present in the conversation.

Exact captured chronology

All timestamps below are UTC on 2026-08-20.

04:46:24: packaged Codex process for the reproduced session started.
04:57:22: screenshot captured while the primary view still displayed Thinking.
04:57:58.867: turn/steer response returned errorCode=-32600.
04:57:58.869: Desktop logged failureReason=no_active_turn and message no active turn to steer.
04:57:59.361: the primary renderer logged ResizeObserver loop completed with undelivered notifications.

The immediately preceding app session also ended with:

04:46:13.632: Received broadcast but no handler is configured method=thread-stream-state-changed.

The reproduced session independently logged completion events for unknown conversations at 04:47:31.852, 04:49:04.848, and 04:49:07.682, plus repeated primary-renderer ResizeObserver errors.

Sanitized log excerpt

2026-08-20T04:57:58.867Z info [AppServerConnection] response_routed conversationId=[REDACTED] errorCode=-32600 method=turn/steer targetDestroyed=false
2026-08-20T04:57:58.869Z error [electron-message-handler] Request failed conversationId=[REDACTED] error={"code":-32600,"message":"no active turn to steer"} failureReason=no_active_turn method=turn/steer pendingCountAfter=0
2026-08-20T04:57:59.361Z error [electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications. rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowVisible=true

Previous-session state-update failure:

2026-08-20T04:46:13.632Z warning [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

Why this appears to be a Desktop state-desynchronization defect

The backend explicitly reports there is no active turn.
The UI still shows an active Thinking state.
The final response becomes visible after reloading persisted conversation state through an app restart.
The main Codex process remains responsive and Windows records no application hang/crash event.
The same session contains renderer and missing-handler errors on the completion/state-update path.

Related open reports

openai/codex#34026: completed Windows Desktop threads remain Thinking; follow-ups can return no active turn to steer.
openai/codex#20754: Desktop remains thinking/running after task completion; restart reveals the persisted result.
openai/codex#37584: newer Windows builds show backend/UI desynchronization and infinite Thinking states.

Troubleshooting intentionally not performed

No app reset, Repair, reinstall, cache deletion, state deletion, configuration change, process termination during capture, or account/session reset was performed. The goal was to preserve the failing state and collect read-only evidence.

Attachments

codex-desktop-stuck-thinking-20260820.png
CODEX_DESKTOP_WINDOWS_STATE_DESYNC_EVIDENCE_20260820.txt
MANIFEST_SHA256_20260820.txt

Privacy note

Conversation IDs, request IDs, local user paths, and private conversation content are removed from the public-facing evidence. The screenshot contains only the word Thinking.

CODEX_DESKTOP_WINDOWS_STATE_DESYNC_EVIDENCE_20260820.txt

MANIFEST_SHA256_20260820.txt

Prepared packet identities (SHA-256): report C0E266CCA41F717C2BC0B32A6E6CA2A3C18D02DB5A592174A289060884A48050; evidence 6B6FE92091BBF0B248C16095DD31456401779DEA9253B22BDB0A07F8593571C1; screenshot B63383AA430A63DCF749DBDF60C9F4777337F8BFA9AC0C739E47A465DC06FFA9.

Additional Windows reproduction that appears to extend this issue with a usage/rate-limit recovery correlation.

Environment

Windows x64 (Microsoft Windows NT 10.0.19045.0)
Codex app-server log client version: 26.814.41957
Bundled Codex runtime observed in logs: 26.814.41407
Codex CLI: 0.147.0
Local-project threads

Observed behavior

After multiple tasks stopped at a Codex usage/rate limit, the expected limit-reset time passed, but remote/programmatic thread management did not recover.

In the affected state, each of these operations hung without a structured error:

list projects
list threads
create a thread
send a follow-up to an existing idle thread

A fresh read-only probe of the simplest operation still failed to return after more than 60 seconds. Retrying with a minimal one-line follow-up had the same result.

Read-only local thread metadata remained unchanged after the attempted follow-ups: no user event was recorded, the thread update timestamp did not move, and no follow-up turn was created. This avoids interpreting a slow response as a successful queued send.

The account owner reports a recurring recovery pattern: after the rate limit has reset, direct interaction with the local Codex Desktop window appears to wake the app, while remote control/programmatic task management remains unresponsive. I could independently reproduce the RPC hang in the current state, but did not independently perform the local-window wake step during this capture because the owner was remote.

This may share the stale renderer/backend lifecycle mismatch described in this issue, but I am not claiming the same root cause. The additional correlation is:

usage/rate limit reached
-> tasks stop
-> reset time passes
-> thread-management RPCs remain hung
-> local foreground/UI interaction appears necessary to resume

Expected behavior / improvement request

Usage-limit recovery should be driven by an authoritative backend entitlement/reset event or app-server lifecycle event, not renderer focus, window activation, or local user input.
While limited, thread-management RPCs should return a typed, bounded error with reset/retry information instead of hanging.
After reset/reconnect, Desktop should proactively reconcile stale stream/turn state and re-enable turn/start, queued follow-ups, and thread-management RPCs.
A stale Thinking/active-turn state should be cleared from authoritative thread/latest-turn state, with at most one idempotent retry using the original client message ID.
Remote task management should have a bounded timeout and an actionable recovery result rather than waiting indefinitely.
If a local UI wake event currently performs hidden reconciliation, that same reconciliation should run on rate-limit reset, reconnect, foreground/background transition, and remote RPC admission.

No thread IDs, prompts, project/repository names, local paths, raw databases, credentials, or private logs are included. Targeted redacted event names/timestamps can be provided if maintainers need them.

Additional Windows reproduction on a newer build, submitted with the account owner's explicit authorization.

Environment

Windows x64
Microsoft Store/MSIX package observed from the running process: OpenAI.Codex_26.818.2441.0_x64__2p2nqsd0c76g0
Desktop client version recorded by app-server logs: 26.818.21641
Bundled command runner observed: 0.148.0-alpha.21
Local-project thread

Reproduction and observed behavior

Continue a long existing local-project thread.
The thread performs automatic context compaction.
Start the next turn.
Desktop remains at Thinking and renders none of the agent commentary, command activity, file changes, or final response.
Read-only thread inspection shows that the same turn is actively producing commentary, command executions, and file changes.
The turn later reaches completed with error: null, and the authoritative thread status becomes idle, while Desktop still shows the stale state.
Switching to another task and back does not recover the transcript.
Programmatically navigating back to the same task also does not recover it.
Only a full Desktop restart reloads the persisted final response and clears the stale Thinking view.

In this capture, the hidden turn ran for about 371 seconds and completed successfully. Its final response and all intermediate events were already readable through the local thread API before the Desktop UI displayed them.

Sanitized local evidence

The SQLite feedback log contained these state-reconstruction warnings around the failure:

dropping turn tool count update: missing turn state
ignored world-state patch without a full snapshot

The ignored world-state patch without a full snapshot warning appeared during resume_thread_with_history -> apply_rollout_reconstruction, both before and after the automatic compaction boundary.

A compacted sequence was observed in this order:

missing turn state
-> thread resume / rollout reconstruction
-> automatic context compaction
-> next turn starts and executes normally in the backend
-> Desktop remains at Thinking
-> turn completes with error: null
-> switching tasks does not recover
-> full app restart reveals the persisted result

There was no matching Windows Application Error or application crash event during the captured session. The main Desktop process remained responsive. The backend distinguished the real running state (active + inProgress) from the completed state (idle + completed); the renderer did not reconcile to either state correctly.

Expected behavior

After compaction, resume, or rollout reconstruction, Desktop should:

rehydrate a complete authoritative thread snapshot;
subscribe to and render subsequent commentary/tool/final events;
clear Thinking when the turn reaches completed;
recover by reopening the thread without requiring a full application restart;
surface an actionable reload/reconciliation control if live state cannot be reconstructed.

Privacy

Thread IDs, project/repository names, local paths, prompts, private task content, request IDs, and credentials are intentionally omitted. Screenshots and narrowly redacted timestamps can be provided if maintainers need them.

Follow-up on the same reproduction: the local-interaction wake correlation reproduced immediately.

After the account owner returned home and interacted directly with the local Codex Desktop window:

the same read-only list projects operation that had hung for more than 60 seconds returned in approximately 0.1 seconds;
two follow-up RPCs to existing idle local threads returned in approximately 0.9 seconds and 0.4 seconds;
an immediate authoritative snapshot showed both new turns as active / inProgress.

Before that local window interaction, repeated list/create/follow-up operations had hung, and read-only thread metadata showed that no follow-up turn was created. No application restart, account change, repository change, new thread creation, or prompt redesign occurred between the failed and successful probes.

This materially strengthens the hypothesis that some renderer-focus/window-activation/local-input path triggers hidden app-server/thread-state reconciliation after a usage-limit interruption. It still does not identify the exact event or prove rate limiting is the sole root cause.

Expected correction remains: run the same reconciliation from authoritative usage-reset/reconnect/lifecycle events and remote RPC admission, without requiring local foreground interaction.

I can reproduce a closely matching failure on Codex Desktop for Windows x64, version 26.818.3698.0.

Observed behavior (repeated more than once):

A long-running local-project task finished its prior turn.
The user sent follow-up commands such as “continue”, but the task produced no acknowledgement, no command/tool activity, and no visible error.
Inspection through the local thread API showed the thread as idle and the latest turn as completed with no error — so it was not actually executing.
Sending the same continuation through the thread API immediately created a new turn; an immediate status snapshot changed to active with the new turn inProgress.

This suggests the backend thread remained resumable, while the Desktop chat input/state reconciliation failed to create or surface the follow-up turn. From the user’s perspective the command was silently ignored. Because there is no explicit failure state, it is easy to assume work is still running or to send duplicate instructions.

Expected behavior:

A completed/idle task accepts the next chat message and starts a new turn.
If the message cannot be submitted, Desktop shows an explicit retryable error.
UI activity/input state reconciles with the backend idle/completed state.

No project paths, prompts, or thread identifiers are included here for privacy. This appears to persist in a substantially newer Desktop build than the one in the original report.

补充一个在 Windows 11 上重复发生的同类案例。

实际现象

在 Codex Desktop 的本地项目线程中，曾多次出现：

UI 不能发送新消息；
UI 也不能停止当前会话；
但通过线程读取接口核验时，线程实际状态为 idle，并不存在可停止的活动轮次；
历史上还出现过上一轮为 interrupted、Desktop UI 与后端状态不同步的情况。

本次代表性案例中，线程读取结果显示 status.type=idle；随后通过官方线程接口发送一条普通 follow-up 后，后端才创建了新的 inProgress 轮次，线程状态恢复为 active。这说明问题不是消息内容或任务仍在正常运行，而是 Desktop 的发送/停止控件没有正确反映 app-server 的真实状态。

用户侧已经明确反馈：该问题不是偶发一次，而是已经遭遇多次。

Expected behavior

后端为 idle 时，发送框应可用，停止按钮应禁用；
后端存在 inProgress 轮次时，发送/停止状态应准确对应；
UI 与 app-server 状态不一致时，应自动 reconciliation，并提供明确的恢复或重试；
不应出现“既不能发送，也不能停止”的无操作状态。

Environment

OS: Windows 11 Professional, build 22621
Codex CLI/runtime reported locally: codex-cli 0.147.0
Product: Codex Desktop
Recurrence: multiple occurrences across local project threads

No private prompts, local paths, credentials, or session contents are included.

I can reproduce this on Windows Desktop 26.820.60940
(MSIX OpenAI.Codex 26.820.7780.0).

This became visible while diagnosing #40715.

After applying the valid disabled codex_app override from #40715,
existing local threads now successfully resume:

thread/resume ... errorCode=null

but multiple unrelated existing local threads then log:

maybe_resume_success
latestTurnStatus=completed
markedStreaming=true

The conversation history renders correctly, but the composer Send button is
disabled/grey even with plain text entered.

Controls:

new local chats are sendable;
existing local chats are affected across unrelated projects;
both WSL-native and Windows-backed local projects reproduce it;
an SSH/remote existing thread remains usable;
switching threads or fully restarting Desktop does not reliably clear it.

This looks like the same completed-thread / stale-streaming reconciliation
failure described here, now reproduced on 26.820.60940.

The underlying thread data remains readable and thread/resume succeeds.

Current-version remote-host reproduction: Desktop stays on "Loading task" and never sends `thread/resume`

I can reproduce a related failure on the current Windows Desktop package, but with an SSH-backed Linux task and stronger transport evidence.

Environment

Windows 11 ARM64
Codex Desktop: 26.825.4187.0
Desktop-bundled runtime: codex-cli 0.150.0-alpha.12.2
Remote Linux app-server: codex-cli 0.150.1
Persisted history mode: legacy

Observed state

The task is large but structurally readable:

rollout exists and is readable;
size: 441,683,165 bytes;
104,357 valid JSONL records;
invalid_json_lines=0;
159 compaction records;
state row, rollout identity, and task CWD agree;
native task reading returns the newest turns, including an interrupted turn with 97 projected items and earlier completed turns with 12 and 140 items;
the task inventory reports status.type = notLoaded.

After opening the task in Desktop, the UI remains indefinitely on Loading task.

The important transport observation is that the Desktop navigation operation reports success, but the remote app-server receives no corresponding thread/resume request. Its last log record for this task predates the navigation attempt, and a targeted query found zero later thread/resume records. There is also no active-writer conflict or resume error on the remote side.

This means the request is being lost before the remote app-server can parse or reject it. The spinner is not evidence that the 441 MB rollout is still being loaded: the server was never asked to resume it.

Expected behavior

Opening a notLoaded remote task should:

issue exactly one thread/resume request to the selected host;
either render the readable projected history or show a bounded, actionable error;
never leave the renderer on an unbounded loading state when no resume RPC is in flight.

Actual behavior

Desktop reports successful navigation.
The renderer shows Loading task indefinitely.
The remote app-server sees no thread/resume.
The same task remains readable through the native task-read surface.
Restarting or repeatedly navigating does not materialize a resume request.

This looks like a Desktop host-routing or renderer state bug before app-server transport, not persisted-history corruption and not the stale-active server-side hang described in #37047.

A useful regression test would open a large notLoaded task on a remote host, assert that navigation emits one host-qualified thread/resume, and fail the UI state if no RPC is dispatched within a short deadline.

Additional Windows reproduction on a newer Desktop build, reported with the account owner's explicit authorization.

Environment

Windows x64
Microsoft Store/MSIX package observed from the running executable path: OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0
Local-project task
Model selector showed 5.6 Sol Ultra during the affected turn

Observed behavior

Continue a long local-project task that is running shell commands and using sub-agents.
The task view stops showing new useful progress and remains at Thinking.
The composer still shows the square Stop control, and the task keeps a spinning activity indicator in the sidebar.
Sending a short follow-up asking whether there is a problem does not restore visible progress or produce an acknowledgement.
The user has to stop/abandon that task and continue the work from another task.

The app itself did not visibly crash. The failure is that the visible turn/control state becomes unusable: the user cannot tell whether the backend is still doing useful work, stalled, or detached, and the follow-up does not recover the stream.

This closely matches the stale active-turn / renderer reconciliation cluster in this issue and confirms that it persists on package 26.818.8289.0.

Expected behavior

Visible progress should continue while a turn is active.
If the backend is no longer active, Desktop should clear Thinking and the Stop state automatically.
A follow-up sent while the UI is stale should either steer the real active turn or return a bounded, actionable error.
If stream ownership is lost, Desktop should offer an explicit reattach/reload action rather than an indefinite Thinking state.

Privacy

A screenshot was captured locally, but it contains private project/task names and conversation content, so it is not attached publicly. No thread IDs, local paths, prompts, credentials, or private source content are included here.

Reproduced this on a newer build — sharing log-level evidence in case it helps narrow down the root cause.

Codex Desktop version: 26.915.31945 (MSIX, x64) Underlying codex-core version: 0.155.0-alpha.9.2 OS: Windows 10 Pro, x64

What happened: Sent a first message in a chat, got a normal reply (turn/completed). About a minute later, with no other activity, the backend logged that the thread was idle with no subscribers and shut it down on its own. Sending the next message triggered a thread/start request to resume/recreate the session — and that request never completed. No error, no timeout surfaced in the UI: the send button just stayed active with no response, indefinitely (observed for several minutes). Other app functionality (e.g. opening the model picker) kept working, so this is scoped to the thread/turn pipeline, not a full app freeze — consistent with what's described here.

Relevant excerpt from the local app-server log (logs_2.sqlite, logs table):

INFO codex_app_server::request_processors::thread_lifecycle :: thread has no subscribers and is idle; shutting down
DEBUG codex_app_server::thread_state :: clearing thread listener during thread-state teardown thread_id= listener_generation=1 had_listener=true had_active_turn=false
DEBUG codex_core::session::handlers :: session_loop{thread_id=}: Submission sub=Submission { id: "...", op: Shutdown, ... }
INFO rmcp::service :: app_server.request{... rpc.method="thread/start" rpc.request_id=thread/start:<req_id> ...}
INFO codex_core::session::handlers :: session_loop{thread_id=}:submission_dispatch{op.dispatch.shutdown}: Shutting down Codex instance
DEBUG codex_core::session::handlers :: session_loop{thread_id=}: Agent loop exited
TRACE codex_app_server::outgoing_message :: app-server event: thread/status/changed
TRACE codex_app_server::outgoing_message :: app-server event: thread/closed
INFO rmcp::service :: app_server.request{... rpc.method="thread/start" rpc.request_id=thread/start:<req_id> ...} <-- same request_id logged again right after teardown, then nothing further ever gets logged for it
After that last line, no further session_loop, submission_dispatch, or turn log entries ever appear for that request — confirmed by re-checking the log ~2.5 minutes later (unrelated log activity, e.g. a list_models call from opening the model dropdown, kept appending fine in the meantime). So the thread/start meant to resume the just-idled thread appears to get dropped/deadlocked somewhere between the shutdown-teardown completing and the new session actually being (re)initialized.

Also noticed these config-mismatch warnings right before this happens each time a thread starts, which might be a red herring or might be related to feature-flag state getting out of sync between the desktop shell and the bundled core:

WARN codex_app_server::request_processors::config_processor :: ignoring invalid experimental feature enablement keys: apps_mcp_path_override, local_thread_store_co...
WARN codex_features :: unknown feature key in config: thread_tools
Happy to pull more detail from the local log DB (full logs table schema: id, ts, ts_nanos, level, target, feedback_log_body, module_path, file, line, thread_id, process_uuid, estimated_bytes) if it's useful — just let me know what to grep for.

Windows Desktop 26.715.4045.0: completed threads remain “thinking”; new messages queue locally and cannot start a turn #34026

Description

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Representative evidence

Steps to reproduce

Expected behavior

Actual behavior

Troubleshooting already attempted

Impact

Related issues

Activity

github-actions commented on Jul 18, 2026

a16797 commented on Jul 20, 2026

kalcypher-mykrobial commented on Jul 27, 2026

Environment

Reproduced lifecycle

Build-specific renderer source isolation

Public app-server source seam

Narrow Desktop correction

Recovery control

harryshawk commented on Aug 15, 2026

labolabo commented on Aug 19, 2026

Additional reproduction on current Windows build 26.814.5517.0

darkchld commented on Aug 20, 2026

tmyhyqsdmj-ship-it commented on Aug 20, 2026

[Windows][26.814.5517.0] UI remains "Thinking" after backend turn completes

Summary

Environment

Actual behavior

Expected behavior

Reproduction

Exact captured chronology

Sanitized log excerpt

Why this appears to be a Desktop state-desynchronization defect

Related open reports

Troubleshooting intentionally not performed

Attachments

Privacy note

amatsuki5032 commented on Aug 20, 2026

Environment

Observed behavior

Expected behavior / improvement request

Kairos-931 commented on Aug 20, 2026

Environment

Reproduction and observed behavior

Sanitized local evidence

Expected behavior

Privacy

amatsuki5032 commented on Aug 20, 2026

Walfg commented on Aug 22, 2026

0okay commented on Aug 24, 2026

实际现象

Expected behavior

Environment

TrinityLGG commented on Aug 26, 2026

nos1609 commented on Aug 28, 2026

Current-version remote-host reproduction: Desktop stays on "Loading task" and never sends thread/resume

Environment

Observed state

Expected behavior

Actual behavior

berkyuo2-cpu commented on Aug 28, 2026

Environment

Observed behavior

Expected behavior

Privacy

trandaiedu25 commented on Sep 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Additional reproduction on current Windows build `26.814.5517.0`

Current-version remote-host reproduction: Desktop stays on "Loading task" and never sends `thread/resume`