Windows desktop app repeatedly restarts after corrupted local state; chat_processes.json can become all NUL bytes #29593

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Jun 23, 2026
2. HyperSpAceBoy commented on Jul 13, 2026

   

   HyperSpAceBoy

   on Jul 13, 2026 – with ChatGPT Codex Connector

   More actions

   Current-build source still lacks atomic writes and malformed-file recovery

   I hit the same Windows corruption shape on recent 26.707 Desktop builds:

   • process_manager/chat_processes.json: 84,599 bytes
   • every byte: 0x00
   • therefore not valid JSON

   During the affected day, sanitized Desktop-log counts included:

   • 2,837 JSON-parse / chat-process notification registration warnings
   • 3,135 Conversation state not found errors
   • 38 unhandled ipc-connection-reset broadcasts
   • 10 EPIPE socket errors
   • 9 response_orphaned records

   I am not claiming every adjacent state error was caused solely by this registry, and Windows WER did not provide enough evidence to label every disappearance a native crash. The proven defect is that one malformed local registry remained on a hot notification path and generated thousands of failures without self-recovery.

   After updating/restarting into Desktop 26.707.8479.0, the registry on this machine was recreated as valid JSON and the NUL parse spam stopped. That is a recovery event, but it is not evidence of a durable fix.

   Read-only inspection of the current 26.707.8479.0 production bundle still shows:

   • the loader catches only ENOENT
   • JSON.parse failure is rethrown
   • malformed schema data falls back to an empty list, but malformed JSON does not
   • the writer calls writeFile(finalPath, JSON.stringify(...)) directly
   • no same-directory temp file + replace/rename
   • no quarantine of malformed state
   • no automatic rebuild path
   • no backup generation/counter

   The current session also continues to log hundreds of Conversation state not found / unknown conversation messages, although I am treating that as adjacent state churn rather than attributing all of it to this file.

   Please do not close this based only on one update/restart recreating the file. Required fix:

   1. atomic same-directory temp write followed by replace/rename
   2. startup/read validation with malformed-file quarantine
   3. automatic rebuild to a valid empty registry
   4. bounded logging instead of thousands of repeated parse failures
   5. regression tests for all-NUL, truncated, empty, and interrupted-write files
   6. isolate registry failure so process notifications cannot destabilize conversation/turn state

   A desktop app must survive corrupt cache/registry state without repeated restarts, log storms, or unsupported manual surgery.
3. faekz0r commented on Jul 18, 2026

   

   faekz0r

   on Jul 18, 2026 – with ChatGPT Codex Connector

   More actions

   Corroborating this on a newer Windows Desktop build, with a 0-byte variant and a less severe user-visible symptom.

   Environment

   • Windows 11 Pro, build 26200, x64
   • Codex Desktop package: OpenAI.Codex 26.715.2305.0

   Observed state

   %USERPROFILE%\.codex\process_manager\chat_processes.json existed but was exactly 0 bytes. Its last-write timestamp preceded the next Windows reboot; I cannot confirm what originally truncated it.

   During the following Codex session, the Desktop log recorded 154 failures of this form:

   warning [electron-fetch-handler] Failed to register chat process notification
   errorMessage="Unexpected end of JSON input"
   errorName=SyntaxError
   at JSON.parse
   method=item/started
   

   The same error also occurred for method=item/completed, effectively twice around many command/tool events.

   The user-visible symptom was intermittent, very short pauses in Codex's text composer while a long-running task was actively doing work: typed characters would briefly stop appearing and then catch up. There was no renderer crash, GPU-process crash, OOM event, paging pressure, CPU run queue, or disk-latency spike in concurrent checks. The parse/retry/log path is therefore a plausible contributor to the composer stalls, although that timing relationship is an inference rather than a captured UI trace.

   Workaround and verification

   I backed up the empty file, then initialized it to valid empty JSON:

   []

   Codex remained open. It subsequently populated the file with valid process records. After the repair:

   • new item/started and item/completed events were handled;
   • the file remained valid JSON;
   • the parse-error count stopped at 154;
   • no new Unexpected end of JSON input warnings appeared across multiple subsequent tool events.

   This supports the same defensive fixes proposed in the original report:

   1. write this state atomically;
   2. treat an empty or invalid file as recoverable state;
   3. quarantine/rebuild it automatically;
   4. avoid retrying and logging a full parse exception on every process notification.

   Raw logs and the process-record contents are not attached because they can contain local paths and command strings, but additional sanitized timestamps/counters can be provided if useful.
4. abiodunonanuga commented on Jul 22, 2026

   

   abiodunonanuga

   on Jul 22, 2026 – with ChatGPT Codex Connector

   More actions

   Corroborating this again on a newer Windows Desktop build, with direct conversation-recovery impact.

   Environment

   • Windows 10 Home 22H2, build 19045.6466, x64
   • Codex Desktop package observed during the failure: OpenAI.Codex 26.715.10079.0
   • Local thread; no SSH/remote host involved

   Malformed state and log evidence

   %USERPROFILE%\.codex\process_manager\chat_processes.json exists but is exactly 0 bytes (last write: 2026-07-20 12:18 local time).

   On 2026-07-22, the Desktop log recorded 137 failures between 18:00:07Z and 18:16:21Z:

   warning [electron-fetch-handler] Failed to register chat process notification
   errorMessage="Unexpected end of JSON input"
   errorName=SyntaxError
   at JSON.parse
   method=item/started
   

   The same failure also occurred for method=item/completed.

   The process then logged:

   2026-07-22T18:16:25.273Z warning [IpcClient] Received broadcast but no handler is configured method=ipc-connection-reset
   2026-07-22T18:16:25.308Z info [AppServerConnection] ... cause=stop_process ... previous=connected next=disconnected
   

   A new Desktop/app-server process started immediately afterward. A second ipc-connection-reset and disconnect occurred at 18:20:59Z, followed by another process start.

   User-visible impact

   This was not limited to log spam or brief composer pauses:

   • A long-running local thread changed to systemError.
   • Reopening the thread did not recover it.
   • Multiple new user messages were appended to the thread history and marked completed, but no agent response was produced.
   • Work had to continue in a newly created thread, requiring state/artifact recovery from the failed conversation.
   • The underlying conversation history remained readable; the failure was specifically the inability to reconnect and continue execution in that thread.

   I have not modified or deleted the empty registry, so this report describes the failure state as observed. I am not claiming the 0-byte registry proves every adjacent connection reset was caused by it, but the repeated JSON.parse failures on the chat-process notification path and the same-session thread failure make the recovery/isolation requirement materially stronger.

   Expected behavior: an empty or malformed process registry should be quarantined/rebuilt automatically and must not cause an existing thread to enter an unrecoverable systemError state or silently accept turns without agent responses.

   Raw logs are not attached because they include local paths, conversation content, and tool outputs. Sanitized excerpts or counts can be provided if maintainers need them.
5. abiodunonanuga commented on Jul 22, 2026

   

   abiodunonanuga

   on Jul 22, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up: I found and verified a second, newly created local thread that later failed in the same session.

   This matters because the second thread was created specifically to recover from the first failed thread; it was not the original 1.2 GB conversation.

   Second-thread evidence

   • Created: 2026-07-22 18:22:46Z
   • Codex Desktop process: OpenAI.Codex 26.715.10079.0
   • CLI/app-server version recorded by the thread: 0.145.0-alpha.30
   • Rollout at failure: 47,619,125 bytes / 497 JSONL records
   • Current Desktop task-list status: systemError
   • %USERPROFILE%\.codex\process_manager\chat_processes.json remained 0 bytes

   The recovery thread initially operated normally: it read the failed thread's history, recovered artifacts, ran tools, coordinated subagents, generated images, and modified local project files.

   Then six separate turns ended with:

   stream disconnected before completion:
   error sending request for url
   (https://chatgpt.com/backend-api/codex/responses)
   

   Failure window:

   first failed turn: 2026-07-22T18:44:40.258Z
   last failed turn:  2026-07-22T19:12:47.097Z
   

   Some turns emitted partial agent commentary or completed tool/file operations before the stream disconnected, but every affected turn ended with the backend-stream error. After the final failure, the new recovery thread itself became systemError and another new chat had to be created.

   Updated interpretation

   The original thread's 1.2 GB history may have made that specific thread difficult to load, but it cannot by itself explain this second failure: a new recovery thread also failed repeatedly and became unusable after about 50 minutes.

   The 0-byte chat_processes.json was global state shared across both failures and was not automatically rebuilt. This recurrence is consistent with malformed process-registry state destabilizing more than one conversation, although it still does not prove that the registry caused every backend disconnect.

   The required recovery behavior should therefore include both:

   1. automatically quarantine/rebuild an empty or malformed process registry; and
   2. prevent one global state failure or stream-disconnect sequence from permanently marking multiple otherwise recoverable threads as systemError.

   Raw rollout and Desktop logs are not attached because they contain local paths, conversation content, generated-image payloads, and tool outputs. Sanitized per-turn timestamps and IDs can be provided if needed.
6. dimasyankauskas commented on Jul 25, 2026

   

   dimasyankauskas

   on Jul 25, 2026 – with ChatGPT Codex Connector

   More actions

   macOS truncated-file variant on current Desktop build

   Corroborating this on macOS with ChatGPT Desktop 26.721.41059 (build 5848).

   Read-only inspection found ~/.codex/process_manager/chat_processes.json in a different malformed state from the previously reported zero-byte/all-NUL variants:

   • exact size: 2,621,440 bytes (0x280000)
   • valid UTF-8 but invalid JSON
   • begins as an array
   • ends inside an unterminated command string
   • no closing string quote, array bracket, or trailing newline
   • the malformed file survived a clean application restart

   In one fixed post-restart log window, the same file produced 1,169 Failed to register chat process notification warnings, approximately evenly divided between item/started and item/completed.

   Read-only inspection of the installed bundle shows that the loader retries the file whenever the in-memory record cache remains unset, while malformed JSON is rethrown rather than quarantined or rebuilt. The writer serializes directly to the final path with writeFile(...); I did not find a same-directory temporary write plus atomic replacement. The registry is limited by record count, but I did not observe a bound on an individual command string.

   The exact 2.5 MiB boundary is consistent with an interrupted chunked write, but I do not have contemporaneous crash evidence proving what interrupted it.

   I am not claiming that this registry caused every adjacent conversation-state warning. The confirmed cross-platform defect is that a truncated registry remains permanently active on a hot notification path with no automatic recovery.

   Raw logs and the registry are intentionally not attached because they contain command strings, local paths, and conversation identifiers.