Codex Desktop: runtime refresh restarts app-server after turn/start and leaves turn permanently stuck

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

26.707.72221 (5307)

What subscription do you have?

Team

What platform is your computer?

Darwin 25.5.0 x86_64 i386

What issue are you seeing?

A newly created local thread accepted a prompt successfully, but approximately
one second later the primary-runtime/plugin refresh restarted the Codex app-
server.

The active turn did not resume. Codex Desktop remained indefinitely in a
working/streaming state, while producing no reasoning, assistant messages,
token events, or tool calls. Stop, retry, and normal interaction were
ineffective.

Affected session:

019f6247-af8e-7e50-a3c9-620dfbd88c47

Relevant UTC timeline:

```text
20:18:25.304 Conversation created
20:18:25.407 primary_runtime_install_started
20:18:25.422 turn/start succeeded, errorCode=null

20:18:26.538 AppServerConnection: Restart requested
hostId=local
killCodexProcess=false
transportKind=stdio

20:18:26.539 app-server state: connected -> disconnected
20:18:26.541 app-server state: disconnected -> restarting

20:18:26.542 primary_runtime_skills_reload_failed
"Codex app-server is not available"

20:18:26.561 ThreadMetadataGenerationService failed
"Codex app-server is not available"

20:18:26.601 Request failed while loading apps
errorCode=-32000
"Codex app-server is not available"

No model output, tool call, token event, or terminal turn state followed.

After completely quitting and reopening Codex Desktop, the logs reported:

latestTurnStatus=interrupted
markedStreaming=true

Resending the identical prompt after restarting the application worked
normally: reasoning appeared within approximately nine seconds and the first
tool call followed shortly afterward.

The prompt contained private local-project details and is not included
publicly. Its content was not changed between the failed and successful
attempts.

What steps can reproduce the bug?

```markdown

1. Keep a large, long-running local thread visible in Codex Desktop.
2. Create a new clean local thread.
3. Submit a substantial coding prompt immediately after creating the thread.
4. Allow a bundled primary-runtime or plugin refresh to occur concurrently.
5. Observe that turn/start succeeds.
6. The runtime refresh requests an app-server restart immediately afterward.
7. The UI remains in a false working/streaming state without model output or

tool activity.

1. Attempting Stop, Retry, or normal interaction does not recover the turn.
2. Completely quit and reopen Codex Desktop.
3. The turn is then shown internally as interrupted, despite having

previously remained marked as streaming.

1. Resend the identical prompt; it now executes normally.

Affected session:

019f6247-af8e-7e50-a3c9-620dfbd88c47

During the frozen interval, its rollout remained at:

• 10 JSONL records
• 112,895 bytes
• no token_count event
• no reasoning or tool-call event

Therefore token usage for the frozen turn itself is unavailable.

The configured model context window, observed after recovery, was 258,400
tokens.

A previously visible large thread may have contributed to state reconciliation
pressure:

• Session: 019f56e5-1ff5-7530-8d72-fd835e116632
• Rollout size: 70,017,759 bytes
• Records: 20,831
• Cumulative counter: 510,185,432 total tokens
• Cached input: 496,580,864 tokens
• Weekly rate-limit usage at completion: 31%

While the clean turn was frozen, Desktop repeatedly requested thread/turns/
list for this older thread.

What is the expected behavior?

A runtime or plugin refresh should not leave an accepted active turn
permanently detached.

Codex Desktop should do at least one of the following:

• postpone the app-server restart until the active turn reaches a safe

boundary;

• automatically resume the turn after the restart;
• immediately mark the turn as interrupted and expose functional Retry and

Cancel controls.

The UI must not remain indefinitely in a false working or streaming state when
no active turn is progressing.

Additional information

No macOS crash report was generated. The application process remained alive;
recovery required completely quitting and reopening Codex Desktop.

A related issue describes similar UI/session desynchronization:

https://github.com/openai/codex/issues/24287

However, that report explicitly describes cases without an observed automatic
restart. This occurrence has a timestamped primary-runtime refresh and app-
server restart immediately after turn/start, followed by zero model or tool
activity.

Relevant local artifacts are available and can be provided as targeted,
redacted excerpts:

• affected session rollout under ~/.codex/sessions/2026/07/14/
• pre-restart Desktop log under ~/Library/Logs/com.openai.codex/2026/07/14/
• post-restart Desktop log showing latestTurnStatus=interrupted and

markedStreaming=true

I have not attached the complete raw rollout or logs because they contain
local paths, prompts, and potentially private project information.