Codex Desktop loses initial prompt when primary-runtime sync restarts app-server during turn startup

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

ChatGPT/Codex Desktop 26.707.71524 (build 5263)

The app-server involved in the incident reported 0.144.2.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.5.1 (build 25F80), Apple Silicon / arm64

What issue are you seeing?

I started a new local Codex thread and submitted a long, carefully written prompt. Codex created and opened the thread, but the message never appeared and no agent response followed.

This almost resulted in complete loss of user-authored data. The affected thread transcript did not contain the prompt at all. I was only able to recover it through a manual forensic search: the full text happened to remain in ~/.codex/.codex-global-state.json, under an electron-persisted-atom-state.prompt-history.client-new-thread:* entry. A normal user would have no reason to know that recovery path exists, and that cache is not a safe substitute for durable thread history.

Affected thread:

019f5ec7-440b-7340-bca4-43990f8cba24

The rollout file contained exactly two JSONL records:

{"timestamp":"2026-07-14T03:59:07.264Z","type":"session_meta","payload":{"session_id":"019f5ec7-440b-7340-bca4-43990f8cba24","cwd":"<local-workspace>","originator":"Codex Desktop","cli_version":"0.144.2","source":"vscode","thread_source":"user","model_provider":"openai","...":"bulky instructions/tool metadata omitted"}}
{"timestamp":"2026-07-14T03:59:07.268Z","type":"event_msg","payload":{"type":"task_started","turn_id":"019f5ec7-4a7b-7733-a84a-90bc7e3e6b0e","started_at":1784001546,"model_context_window":258400,"collaboration_mode_kind":"default"}}

There is no user-message record, no assistant record, and no task_complete.

The SQLite thread row independently confirms that the message was not durably attached to the thread:

title=<generated from the beginning of the submitted prompt>
first_user_message=""
preview=""
has_user_event=0

The desktop logs show a likely race: turn/start succeeded, then primary-runtime/plugin synchronization restarted the app-server about 1.3 seconds later.

2026-07-14T03:59:06.959Z ... method=turn/start ... conversationId=019f5ec7-440b-7340-bca4-43990f8cba24 ... errorCode=null

2026-07-14T03:59:08.232Z ... plugin_marketplace_sync_completed marketplaceName=openai-primary-runtime ...
2026-07-14T03:59:08.232Z ... Restart requested hostId=local killCodexProcess=false transportKind=stdio
2026-07-14T03:59:08.234Z warning ... primary_runtime_skills_reload_failed errorMessage="Codex app-server is not available"
2026-07-14T03:59:08.238Z warning ... Failed to generate thread title errorMessage="Codex app-server is not available"

2026-07-14T03:59:09.726Z ... maybe_resume_success ... latestTurnId=019f5ec7-4a7b-7733-a84a-90bc7e3e6b0e latestTurnStatus=interrupted ... turnCount=1
2026-07-14T03:59:09.781Z ... app_server_restart_recovery_done ... resumedCurrentConversation=true

The runtime installer subsequently reported status=already-current, so even an already-current primary runtime/plugin synchronization was able to restart the app-server while a newly submitted turn was starting.

This appears to be a durability/race-condition bug between:

1. new thread creation and turn/start;
2. persistence of the initial user message; and
3. app-server restart initiated by primary-runtime/plugin synchronization.

What steps can reproduce the bug?

I have one observed occurrence, not yet a deliberate deterministic reproduction:

1. Open Codex Desktop and select a local workspace.
2. Create a new thread.
3. Enter a long prompt.
4. Submit it while primary-runtime/bundled-plugin synchronization is completing.
5. Codex creates the thread and accepts turn/start.
6. Plugin synchronization requests an app-server restart.
7. Restart recovery marks the new turn interrupted.
8. The UI shows an empty thread; the submitted prompt is absent from the rollout and SQLite thread history.

The timing may require submission during startup/runtime synchronization.

What is the expected behavior?

User-authored text must not be lost after Codex accepts a submission.

At minimum:

• Persist the user message atomically before or with turn/start.
• Do not restart the app-server while a turn is being created or is active; defer the restart until a safe boundary.
• If startup is interrupted, recover/replay the persisted message or restore it visibly to the composer.
• Show an explicit failure/recovery state rather than an empty thread.
• Keep a durable user-accessible recovery path for submitted and unsent composer text.

The prompt-history cache prevented actual data loss in this occurrence, but relying on a hidden global-state cache is unsafe and undiscoverable.

Additional information

Possibly adjacent, but not exact duplicates:

• #23035: orphan task_started after interruption
• #24287: accepted prompts becoming invisible after restart/state desynchronization

This report adds a concrete macOS timeline tying loss of the initial prompt to an automatic app-server restart initiated by primary-runtime/plugin synchronization. The underlying thread never received a user-message event.