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

Open 💬 4 comments Opened Jul 14, 2026 by niieani

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

new thread creation and turn/start;
persistence of the initial user message; and
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:

Open Codex Desktop and select a local workspace.
Create a new thread.
Enter a long prompt.
Submit it while primary-runtime/bundled-plugin synchronization is completing.
Codex creates the thread and accepts turn/start.
Plugin synchronization requests an app-server restart.
Restart recovery marks the new turn interrupted.
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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

#32715

Powered by Codex Action

niieani · 1 month ago

#32715 not a duplicate; but might be related

IvyRoom · 1 month ago

Confirmed the same bug on Windows, with the same primary-runtime/app-server restart race.

Environment

Codex Desktop: 26.707.9981.0
Bundled app-server / CLI: 0.144.2
OS: Windows 11 Pro 25H2, build 26200.8655, x64
Incident: 2026-07-14T15:58:54Z
Affected thread: 019f615a-464e-71f2-9408-530f62bb298f

User-visible result

A carefully written 2,078-character initial prompt was submitted while creating a new local task. The app created the task and generated its title from the prompt, but the prompt never appeared in the conversation and the agent never received it. The first durable user turn in the thread was a later Hello? message at 16:01:10Z.

The full original prompt survived only in:

~/.codex/.codex-global-state.json
electron-persisted-atom-state.prompt-history["client-new-thread:0acd1a25-f9f7-41a2-935e-bd4d3c4278fb"]

The state also maps that temporary client ID to the permanent thread ID, but the prompt was not migrated into the thread transcript. The prompt body is omitted here for privacy.

The rollout began with session_meta and task_started, but contained no initial user-message event. The generated thread title was preserved.

Desktop log timeline

15:58:54.257  Conversation created
15:58:54.278  primary_runtime_install_started (hasConfiguredRuntime=true)
15:58:54.289  turn/start succeeded
15:58:54.851  plugin_marketplace_sync_completed (all 5 plugins skipped_current)
15:58:54.852  Restart requested; app-server transport stopped
15:58:54.855  primary_runtime_skills_reload_failed: "Codex app-server is not available"
15:58:54.856  thread title generation failed: "Codex app-server is not available"
15:58:55.254  primary_runtime_install_finished status=already-current
15:58:55.278  thread/name/set succeeded
15:58:56.924  recovery: latestTurnStatus=interrupted, turnCount=1
15:58:56.944  app_server_restart_recovery_done

This appears to be the same race described in the issue and confirms it affects the Windows desktop app as well. An already-current runtime/plugin sync can restart app-server immediately after turn/start, leaving the title and hidden prompt-history entry but no durable first user message.

erikmagnethi · 1 month ago

Confirmed independently on macOS with the same primary-runtime/app-server restart race.

Environment

ChatGPT/Codex Desktop: 26.707.91948 (build 5440)
Bundled Codex CLI/app-server: 0.144.5
OS: macOS 26.5.2 (build 25F84), Apple Silicon / arm64 (MacBook M2)
Incident: 2026-07-16T14:30:12Z
Affected thread: 019f6b55-bc78-7392-8e6b-d53cbc6b26f7
Temporary client thread: client-new-thread:faf83a2f-7117-4d76-ac22-54aa8e2d1aac

User-visible result

A 3,235-character / 598-word initial prompt was submitted with a PDF attachment after roughly 20 minutes of composition. The task and prompt-derived title briefly appeared, but the conversation body was blank and the agent never received the prompt. The first durable user message in the rollout is a later complaint at 14:36:09Z.

The exact original prompt survived only in the hidden desktop cache:

~/.codex/.codex-global-state.json
electron-persisted-atom-state.prompt-history["client-new-thread:faf83a2f-7117-4d76-ac22-54aa8e2d1aac"]

The prompt content and attachment filename are omitted for privacy. The state also contains the permanent-thread to temporary-client-thread mapping.

The rollout starts with session_meta and task_started at 14:30:12Z, but contains no initial user-message record. This matches the failure pattern reported in the issue.

The user reports this is the third disappearing/blank task occurrence in the desktop app, although only this occurrence has been forensically tied to this exact race.

Desktop log timeline

14:30:12.652  thread/start succeeded
14:30:12.657  Conversation created
14:30:12.692  primary_runtime_install_started (hasConfiguredRuntime=true)
14:30:12.699  turn/start succeeded
14:30:13.664  plugin_marketplace_sync_completed (5 installed before and after)
14:30:13.665  Restart requested; local app-server sidecar stopped
14:30:13.667  primary_runtime_skills_reload_failed: "Codex app-server is not available"
14:30:13.673  thread title generation failed: "Codex app-server is not available"
14:30:13.675  "state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back"
14:30:14.222  primary_runtime_install_finished status=already-current
14:30:14.251  thread/name/set succeeded
14:30:18.199  maybe_resume_success latestTurnStatus=interrupted markedStreaming=true turnCount=1
14:30:18.225  app_server_restart_recovery_done resumedCurrentConversation=true

This confirms the same bug on a newer desktop build and bundled CLI 0.144.5. An already-current runtime sync can still restart the app-server immediately after turn/start, before the user message is durably attached to the thread.

Given that the UI accepts the submission and clears the composer, this is silent user-data loss from a normal user's perspective. The hidden prompt-history cache happened to make forensic recovery possible, but there is no visible recovery affordance.