[macOS Desktop plus Android Remote] list threads reaches app server but never completes; UI sidebar remains healthy.

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

• #37668
• #37556

Powered by Codex Action

Additional current-build reproduction from macOS desktop scheduled automation:

• Codex app: 26.810.52044 (build 6662)
• Bundled CLI/app-server: 0.148.0-alpha.9
• Platform: macOS 26.5.2 arm64
• Subscription: Pro

A standalone projectless cron automation called list_threads({ limit: 10 }) exactly once, sequentially, with no other thread-management calls in flight. The call did not return within 30 seconds. The same list_threads({ limit: 10 }) call from a foreground interactive task completed in 1.44 seconds, and later in 1.17 seconds. Restarting Desktop does not prevent the failure from recurring in later tasks.

Local integrity controls all passed:

• state DB PRAGMA quick_check: ok
• rollout/state inventory parity: no missing, stale, duplicate, or malformed rows
• codex doctor --json: state databases and provider/WebSocket reachability healthy

An additional correlated finding may explain why the task-service path becomes overloaded: read_thread({ includeOutputs: false, maxOutputCharsPerItem: 1000, turnLimit: 1 }) returned a 3,809,394-byte response for a completed thread because three imageGeneration.result blobs were included without truncation (approximately 1.40 MB, 1.32 MB, and 1.05 MB). The tool ignored both includeOutputs: false and maxOutputCharsPerItem for those items.

The active rollout inventory also contained three legacy histories of approximately 566 MB, 374 MB, and 178 MB. The built-in migrate-rollouts dry run marked all three eligible for paginated history. Migrating two completed histories and archiving those completed tasks restored foreground list_threads(limit: 10) latency to 1.17 seconds, but this does not explain or fix why the standalone scheduled call can remain pending while the foreground call succeeds.

This provides two likely interacting defects:

1. Background/standalone task-management routing can stop settling even while foreground routing remains healthy.
2. read_thread can return multi-megabyte image payloads despite explicit output suppression/truncation, increasing queue and memory pressure.

No private paths, prompts, task titles, identifiers, or raw logs are included here. I can provide narrow correlation details privately if needed.

Additional sanitized current-build reproduction narrows the hang to the return leg after the App Server has already answered.

Environment:

• Windows Codex Desktop package 26.820.7780.0, ARM64
• bundled task runtime 0.149.0-alpha.4.1
• directly user-created foreground local task
• list_threads({ limit: 10 })

Observed:

1. The dynamic app-tool log recorded dynamic_app_tool_renderer_execution_started for list_threads.
2. The corresponding underlying thread/list requests reached AppServerConnection.
3. The App Server responses were routed successfully in 17 ms and 43 ms with errorCode=null, hadPending=true, and targetDestroyed=false.
4. The dynamic tool layer never logged its normal Sending server response ... tool=list_threads event.
5. The originating rollout ends at the list_threads function call with no function-call output and remains unchanged for more than 43 minutes.
6. A second independent foreground task invoked list_threads during the same incident; it also remained pending until manually interrupted after 495.8 seconds.
7. Exact-ID read_thread and wait_threads operations remained responsive, and unrelated App Server operations continued completing.

Earlier list_threads calls in the same Desktop process normally completed in roughly 2-3 seconds. The first unreplied dynamic call appears to poison subsequent agent-facing list calls globally.

This is one boundary later than the original reproduction: the request not only reaches the App Server, but successful thread/list responses are already routed. The unresolved promise is between the routed App Server response and the dynamic app-tool reply to the model.

Expected: every dynamic task-tool request must settle with a result or bounded structured error. A successfully routed App Server response must not leave the model turn blocked indefinitely.

No task IDs, turn IDs, call IDs, paths, project names, prompts, account data, hostnames, addresses, or credentials are included.

Cancellation control from the same incident:

• the first unreplied list_threads belonged to a turn that later persisted a turn_aborted event;
• that aborted turn never received a tool response;
• approximately 80 seconds after the abort, a fresh turn in the same task started normally;
• its later list_threads call also remained unresolved;
• a third list call from another foreground task then hung for 495.8 seconds.

Therefore outer turn cancellation does not reliably cancel or reject the pending dynamic app-tool request. The leaked request survives turn_aborted and appears to poison subsequent list_threads calls in the renderer bridge.

Required invariant: aborting a turn must cancel every outstanding app-tool request, reject the model-visible tool promise, remove the call from bridge bookkeeping, and permit the next task-tool call to proceed. A stale request must not survive into later turns.

No task, turn, call, project, path, host, or account identifiers are included.

Recovery outcome from the same current-build incident:

• Invoking the visible Stop control immediately appended turn_aborted for the blocked outer turn in the durable rollout.
• The unresolved list_threads call had not settled naturally. Its model-visible output appeared only during cancellation, roughly 57 minutes after the original call.
• The App Server process was not restarted.
• A renderer-only reload was performed, then the task was reopened.
• A fresh turn started normally. Exact-ID wait_threads, exact-ID read_thread, and dynamic command calls returned, and the new tool stream became visible in the UI.
• list_threads was intentionally not retried, so this does not claim that the poisoned list route recovered.

This confirms two separate recovery boundaries: Stop can terminate the outer turn, but the leaked dynamic request remains unresolved until cancellation; restoring normal renderer tool delivery still requires a renderer reload. Cancellation should settle the tool promise immediately and remove its bridge state without requiring a reload.

No task, turn, call, project, path, host, account, prompt, or credential identifiers are included.