Desktop app hides task interruption/stall, making an inactive Codex run appear to still be working

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

• #32890
• #32467
• #32774
• #32714

Powered by Codex Action

I can reproduce a post-tool continuation stall on Codex Desktop for macOS.

This appears to be more specific than a UI visibility problem: in at least one confirmed occurrence, the persisted rollout itself stopped
immediately after a successful tool result, without any subsequent model continuation or terminal turn event.

## Environment

• Surface: Codex Desktop
• Codex Desktop: 26.707.71524, build 5263
• app-server / codex-cli: 0.144.2
• Platform: macOS
• Session type: local Codex session
• Session metadata originator: Codex Desktop
• Session metadata source: vscode
• At least one confirmed affected turn used gpt-5.6-sol
• The original Codex model path is used; no third-party model proxy is involved
• First observed: July 14, 2026
• The same workflow did not exhibit this behavior during the preceding several days

I am not claiming that the problem is model-specific. The model information is included only to help correlate the affected runtime path.

## Impact

Multiple independent turns have stalled immediately after a tool result was successfully recorded.

The user-visible result is:

• the command has already completed;
• no further assistant progress or response appears;
• the turn remains displayed as active or in progress;
• no automatic timeout, failure, or interruption state appears;
• the user must manually interrupt the turn before continuing.

The Codex Desktop window remains responsive during the stall. The user can switch views and manually interrupt the turn, so this is not a full
application freeze or an operating-system-level process hang.

## Recurring event sequence

The recurring sequence is:

1. The assistant invokes a tool.
2. The command completes successfully.
3. custom_tool_call_output is persisted to the rollout.
4. A token_count event may be persisted immediately afterward.
5. No subsequent agent_reasoning event appears.
6. No assistant message appears.
7. No task_complete, failure, or interruption event appears.
8. Codex Desktop continues displaying the turn as active until the user manually interrupts it.

The suspected failing boundary is:

```text
tool result accepted
-> next model continuation request
-> continuation stream
-> terminal turn state

The failure is not inside the shell command itself.

## Sanitized confirmed timeline

The following is a sanitized timeline from one confirmed occurrence. Session IDs, turn IDs, tool payloads, paths, account information, and
command output have been removed.

04:38:02.605Z event_msg agent_reasoning
04:38:03.859Z response_item custom_tool_call
04:38:05.765Z response_item custom_tool_call_output
tool reported successful completion
wall time approximately 1.9 seconds
04:38:05.766Z event_msg token_count

<no additional event for more than six minutes>
<no agent_reasoning>
<no assistant message>
<no task_complete>
<no failed event>
<no interrupted event>

When the rollout was checked more than six minutes later, its modification time and final event were still unchanged.

In a separate affected turn, the observable state remained equivalent to:

thread status: active
latest turn status: inProgress
completedAt: null
error: none
active flags: none

The last command in that turn had already completed successfully.

## Additional minimal user-visible recurrence

The same user-visible symptom also occurred during a much smaller operation:

1. The assistant read a local Markdown file containing approximately 167 lines.
2. The tool reported successful completion in approximately 0.5 seconds.
3. No visible continuation appeared for approximately two minutes.
4. The user manually interrupted the turn.

This smaller occurrence is important because it did not involve:

• a build;
• a test suite;
• a long-running subprocess;
• ADB;
• a business API;
• a large repository operation;
• a permission request;
• a subagent;
• or an interactive terminal process.

It suggests that large output may increase the probability of the problem, but large output is probably not the only possible trigger.

## Reproduction matrix

The same boundary failure has been observed after different tool workloads:

Tool workload Command completed Post-tool continuation Recovery
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━
Read-only local text search Yes Did not appear Manual interruption
─────────────────────────────── ────────────────────────── ───────────────────────────────────────────────────── ─────────────────────
Small local Markdown read Yes, approximately 0.5 s Did not appear for approximately 2 minutes Manual interruption
─────────────────────────────── ────────────────────────── ───────────────────────────────────────────────────── ─────────────────────
GitHub API metadata query Yes, approximately 1.9 s No subsequent rollout event for more than 6 minutes Manual interruption
─────────────────────────────── ────────────────────────── ───────────────────────────────────────────────────── ─────────────────────
ADB screenshot/log collection Yes No subsequent assistant continuation Manual interruption

The issue is intermittent rather than deterministically reproducible on every tool call.

## What has been ruled out

For the confirmed occurrences:

• the shell command was not still running;
• the tool reported successful completion;
• there was no pending permission or approval request;
• there was no pending user-input request;
• there was no active subagent to wait for;
• there was no background build or test process being awaited;
• the Desktop application itself remained interactive;
• the stall occurred with unrelated command types;
• the rollout contained no terminal error explaining the stopped continuation.

## Possible triggers

The following are hypotheses, not confirmed root causes:

1. The app-server may fail to start or complete the next model request after accepting a tool result.
2. A continuation stream may disconnect or terminate without generating a terminal turn event.
3. The turn state machine may fail to transition from tool completion to either model continuation or failure.
4. Large tool outputs or a long conversation context may increase the probability of the issue.
5. Restored or long-running Desktop sessions may be more susceptible.
6. A recent Desktop, app-server, model-routing, or backend rollout may have introduced a regression.

The timing is notable: this began on July 14, 2026 and was not observed during the preceding several days.

## Expected behavior

After a successful tool result, one of the following must happen:

1. the model continuation starts and the assistant proceeds;
2. the continuation fails and the turn becomes failed;
3. the continuation is disconnected and the turn becomes interrupted;
4. a watchdog detects the absence of progress and terminates the orphaned turn.

The following state should not be possible indefinitely:

tool result persisted

• no continuation
• no error
• no terminal event
• UI still shows active

The Desktop UI should also expose:

• the timestamp of the last successful activity;
• whether it is currently executing a tool, waiting for a model continuation, disconnected, or stalled;
• an explicit timeout, failed, or interrupted state;
• whether a new user message will steer the current turn or start a new one.

## Suggested engineering investigation

It may be useful to correlate the following app-server boundaries for an affected turn:

1. receipt and persistence of custom_tool_call_output;
2. scheduling of the next model continuation request;
3. creation of the outbound continuation stream;
4. first-byte or first-event receipt from that stream;
5. stream close/error/cancellation handling;
6. turn terminalization when the stream ends without a response;
7. Desktop reconciliation of persisted turn status after reconnect or reload.

A watchdog around the interval between persisted tool output and the next model event may also prevent an orphaned turn from remaining active
indefinitely.

## Related issue

This may be related to:

• #32714 — Turn stays running indefinitely after a successful tool result with no post-tool continuation

That issue describes a Windows occurrence. This report adds a macOS occurrence and a sanitized rollout timeline showing that the event stream
itself stopped after the persisted tool result.

## Privacy and diagnostic availability

The following have intentionally been omitted from this public comment:

• session IDs;
• turn IDs;
• account identifiers;
• usernames;
• email addresses;
• IP addresses;
• absolute filesystem paths;
• repository and project names;
• prompts and conversation content;
• business API data;
• command output;
• screenshots;
• device identifiers;
• cookies;
• access tokens;
• credentials;
• authorization headers;
• and raw logs.

If an OpenAI maintainer provides an official private diagnostic channel, the exact affected session IDs, turn IDs, and narrowly scoped redacted
event tails can be provided privately for server-side correlation.

Please do not request that those identifiers be posted publicly.

Additional macOS/Remote data point on Codex Desktop 26.803.61601 (build 6396):

• The turn progressed normally and completed a web-search tool call.
• After 209,356 ms, the turn was recorded as interrupted with error: null.
• The user did not press Stop.
• No final assistant response or visible explanation was produced.
• The last activity was the tool/search boundary, followed by no model continuation.
• A follow-up successfully resumed and completed the work in the same task.

This appears consistent with the post-tool continuation/terminalization failure described in this issue's macOS corroboration. A separate sidebar visibility bug then hid the idle task, making the interruption look like lost work.