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:

1. Let a normal turn finish successfully.
2. Leave the thread idle for a few minutes without sending anything.
3. Return to the same thread and submit a follow-up in the default Steer mode.
4. 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:

1. try steering the current turn;
2. catch an inactive-steer error;
3. 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:

1. structured NoActiveTurnToSteer -> inactive (true)
2. internal SteerTurnInactiveError -> inactive (true)
3. generic Error("no active turn to steer") from an older server -> inactive (true)
4. unrelated -32600 invalid request -> inactive (false)
5. 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.

This is a strong lifecycle control for codex-rescue: the authoritative thread is idle/notLoaded with a completed latest turn, while Desktop still says Thinking and traps follow-ups. Rescue should trust durable session evidence and avoid classifying completed work as interrupted merely from stale UI state.

If you still have an affected local thread, could you run:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

A healthy/no-damage result is the expected useful outcome here. No salvage is needed unless doctor independently finds a genuinely unfinished persisted state; the tool does not fix Desktop steer/queue reconciliation.

Please share sanitized output, versions and exit codes only—no raw rollouts/SQLite, prompts, thread IDs, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

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:

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

1. A normal turn finishes on the backend.
2. Codex Desktop continues to show Thinking and does not display the final response.
3. A follow-up/steer attempt is rejected with no active turn to steer, proving the backend no longer considers the turn active.
4. 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:

1. Launch Codex Desktop on Windows.
2. Open an existing local-project conversation.
3. Send a normal request and wait for completion.
4. Observe that the app remains on Thinking after the response should have completed.
5. Attempt a follow-up or steer action.
6. Observe no active turn to steer in the Desktop log while the UI still appears active.
7. Force-close and reopen Codex.
8. 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

1. 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.
2. While limited, thread-management RPCs should return a typed, bounded error with reset/retry information instead of hanging.
3. After reset/reconnect, Desktop should proactively reconcile stale stream/turn state and re-enable turn/start, queued follow-ups, and thread-management RPCs.
4. 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.
5. Remote task management should have a bounded timeout and an actionable recovery result rather than waiting indefinitely.
6. 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

1. Continue a long existing local-project thread.
2. The thread performs automatic context compaction.
3. Start the next turn.
4. Desktop remains at Thinking and renders none of the agent commentary, command activity, file changes, or final response.
5. Read-only thread inspection shows that the same turn is actively producing commentary, command executions, and file changes.
6. The turn later reaches completed with error: null, and the authoritative thread status becomes idle, while Desktop still shows the stale state.
7. Switching to another task and back does not recover the transcript.
8. Programmatically navigating back to the same task also does not recover it.
9. 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):

1. A long-running local-project task finished its prior turn.
2. The user sent follow-up commands such as “continue”, but the task produced no acknowledgement, no command/tool activity, and no visible error.
3. 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.
4. 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.

My instance of this cluster matched what several people describe: renderer stuck in Thinking while thread/read reports the thread idle. If your transcript matters, verify the data layer before archive/delete attempts make recovery harder - vetto rescue scan lists intact rollouts read-only. Not a fix claim, just a way to separate 'data lost' from 'UI wedged'.

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:

1. issue exactly one thread/resume request to the selected host;
2. either render the readable projected history or show a bounded, actionable error;
3. 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

1. Continue a long local-project task that is running shell commands and using sub-agents.
2. The task view stops showing new useful progress and remains at Thinking.
3. The composer still shows the square Stop control, and the task keeps a spinning activity indicator in the sidebar.
4. Sending a short follow-up asking whether there is a problem does not restore visible progress or produce an acknowledgement.
5. 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.