[Bug/Issue] ChatGPT hit a snag

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

26.825.51511

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Never faced this issue before. It says "ChatGPT hit a snag".

What steps can reproduce the bug?

I can't say exactly how to reproduce this issue. However, when I send a prompt, it works for a few minutes and then this error appears. If I then send another prompt such as, "Please proceed from where you left off," the task resumes briefly but eventually produces the same error again.

What is the expected behavior?

Expected behaviour is that the Prompt shall work and complete rather than giving this error. More details in "Additional Information".

Additional information

Disclosure: I initially documented this issue in detail with ChatGPT and shared the relevant symptoms, environment details, screenshots, logs, and command outputs. ChatGPT suggested several diagnostic commands for me to run, including checks for the installed AppX/MSIX version, Windows Application events, the ChatGPT/Codex process tree, desktop logs, and SQLite integrity.

I ran those commands myself on the affected machine and provided the resulting outputs back to ChatGPT. Based on those actual outputs, ChatGPT helped organize and draft this issue report.

Summary

The unified ChatGPT/Codex Windows desktop app repeatedly loses its local codex.exe app-server.

The backend terminates unexpectedly with:

code=3221225786
hex=0xC000013A
signal=null
classifiedAsExpected=false

The desktop shell (ChatGPT.exe) remains alive. AppServerConnection transitions from connected -> error, the app broadcasts fatal_error_broadcasted, and the UI shows:

ChatGPT hit a snag
Something went wrong. Restart ChatGPT to try again.

The app is subsequently able to spawn/reconnect a new app-server and recover the current conversation.

I have reproduced the same failure multiple times across at least 2026-08-30 and 2026-09-01.

I have already checked the Windows Application event log, MSIX package state, process tree, app-server process, desktop logs, SQLite diagnostic database size/integrity, and backend recovery behavior. Details below.

I have intentionally redacted only user-specific identifiers such as username, conversation IDs, tool-call IDs, pipe UUIDs, and any prompt/conversation content. Log semantics, exit codes, timestamps, process relationships, versions, and error messages are otherwise preserved.

---

Environment

Windows

Microsoft Windows NT 10.0.26200.0 x64
Windows 11

Version discrepancy

The About dialog inside the unified ChatGPT/Codex app reports:

26.825.51511

However, querying the installed Microsoft Store/MSIX package reports:

Get-AppxPackage OpenAI.Codex |
    Select-Object Name, Version, Status, InstallLocation

Output:

Name         Version       Status InstallLocation
----         -------       ------ ---------------
OpenAI.Codex 26.825.6671.0 Ok     C:\Program Files\WindowsApps\OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0

Therefore:

About dialog:       26.825.51511
Installed MSIX:     26.825.6671.0
Package status:     Ok

I do not know whether this mismatch is expected (for example, application/internal build vs package build), so I am reporting both values rather than assuming they should be identical.

The Electron/Chromium crashpad command line also reports:

annotation=prod=Codex
annotation=ver=151.0.7922.174

---

Actual failure signature

On 2026-09-01 the desktop log records:

2026-09-01T05:23:37.547Z info [AppServerConnection]
app_server_connection.closed
code=3221225786
connectionId=1
hasReason=true
signal=null
transport=stdio

Immediately afterward:

2026-09-01T05:23:37.547Z info [AppServerConnection]
app_server_connection.state_changed
cause=transport_closed
closeCode=3221225786
currentState=connected
next=error
wasInitialized=true
wasLoginRequired=false
wasVersionError=false

Then:

2026-09-01T05:23:37.549Z error [AppServerConnection]
Codex CLI process exited
classifiedAsExpected=false
code=3221225786
connectionId=1
signal=null
transport=stdio

And:

2026-09-01T05:23:37.549Z error [AppServerConnection]
fatal_error_broadcasted
errorMessage="  (code=3221225786, signal=null). ..."
initialized=false
pendingRequestCount=0
transportKind=stdio

The frontend then records:

source=fatal_error_message
rendererWindowVisible=true

This corresponds to the visible "ChatGPT hit a snag" fatal-error UI.

3221225786 is:

0xC000013A
STATUS_CONTROL_C_EXIT

I am not asserting what component delivers the control/termination event; the log only establishes how the process exited.

---

Error immediately preceding one of the failures

Immediately before the 2026-09-01 backend termination, codex_core::util emitted:

Custom tool call output is missing for call id: <redacted-call-id-1>
Custom tool call output is missing for call id: <redacted-call-id-2>
Custom tool call output is missing for call id: <redacted-call-id-3>

These messages were propagated as the most recent backend error when the stdio transport closed.

I am not claiming these messages caused the process termination.

They may instead be a consequence of an earlier interrupted turn, e.g. a tool call being persisted without its corresponding output before an app-server termination.

This distinction may be important when investigating the primary kill vs subsequent rollout/thread state.

---

Automatic recovery succeeds

After the fatal broadcast, the desktop app starts a replacement app-server:

2026-09-01T05:24:03.846Z
app_server_connection.state_changed
cause=start_process
currentState=error
next=connecting

Then:

2026-09-01T05:24:04.502Z
cause=post_initialize_connection_state
currentConnectionId=2
hasConnection=true
initialized=true
next=connected

Finally:

2026-09-01T05:24:04.725Z
app_server_restart_recovery_done
currentConversationExistsOnTargetHost=true
currentConversationId=<redacted>
resumedCurrentConversation=true

So the Electron/ChatGPT frontend survives the backend termination and successfully recovers by spawning/reconnecting the app-server.

---

This is reproducible, not a one-off

The same exit signature occurred repeatedly on 2026-08-30.

2026-08-30T14:30:14Z

app_server_connection.closed code=3221225786
cause=transport_closed
closeCode=3221225786

Codex CLI process exited
classifiedAsExpected=false
code=3221225786

fatal_error_broadcasted
code=3221225786
signal=null

The app subsequently reconnects:

app_server_restart_recovery_done
resumedCurrentConversation=true

Interestingly, the "most recent error" associated with this occurrence was only:

Failed to create shell snapshot for powershell:
Shell snapshot not supported yet for PowerShell

I do not consider that warning established as causal.

2026-08-30T14:49:45Z

Again:

app_server_connection.closed code=3221225786

Codex CLI process exited
classifiedAsExpected=false
code=3221225786

fatal_error_broadcasted

A preceding backend message was:

Custom tool call output is missing for call id: <redacted>

Recovery:

app_server_restart_recovery_done
resumedCurrentConversation=true

2026-08-30T16:20:39Z

Again:

app_server_connection.closed code=3221225786

Codex CLI process exited
classifiedAsExpected=false
code=3221225786

fatal_error_broadcasted

Recovery:

app_server_restart_recovery_done
resumedCurrentConversation=true

2026-08-30T16:22:01Z

Again:

app_server_connection.closed code=3221225786

Codex CLI process exited
classifiedAsExpected=false
code=3221225786

fatal_error_broadcasted

Again followed by successful backend restart/recovery.

This is therefore a repeated failure mode across separate app-server generations and separate sessions/dates.

---

Frontend survives / process tree evidence

I inspected the running process tree using:

Get-CimInstance Win32_Process |
Where-Object {
    $_.Name -in 'ChatGPT.exe','codex.exe'
} |
Sort-Object CreationDate |
Select-Object Name,
              ProcessId,
              ParentProcessId,
              CreationDate,
              CommandLine |
Format-List

The main process was:

Name            : ChatGPT.exe
ProcessId       : 33744
CreationDate    : 01-09-2026 10:41:53
CommandLine     : "...OpenAI.Codex_26.825.6671.0...\app\ChatGPT.exe"

Its surviving child processes included:

--type=crashpad-handler
--type=gpu-process
--type=utility --utility-sub-type=network.mojom.NetworkService
--type=utility --utility-sub-type=storage.mojom.StorageService
--type=renderer

The local app-server later present was:

Name            : codex.exe
ProcessId       : 8568
ParentProcessId : 33744
CreationDate    : 01-09-2026 11:14:11

Sanitized beginning of command line:

C:\Users\<redacted>\AppData\Local\OpenAI\Codex\bin\b99306303521e97e\codex.exe
-c features.code_mode_host=true
app-server
--analytics-default-enabled
...

It was therefore an app-managed codex.exe running explicitly in app-server mode and parented by the surviving main ChatGPT process.

A newer renderer also appeared under the same original main process:

Name            : ChatGPT.exe
ParentProcessId : 33744
CreationDate    : 01-09-2026 11:14:27
--type=renderer

The desktop log independently confirms app-server restart/recovery, so this is not a conventional full ChatGPT.exe process crash.

---

Process-health snapshot

I also ran:

Get-Process ChatGPT,codex -ErrorAction SilentlyContinue |
    Select Name,Id,CPU,WorkingSet64,Responding,StartTime

At the time of capture:

All listed ChatGPT.exe processes: Responding = True
codex.exe:                       Responding = True

Approximate working-set observations:

codex.exe:             ~153 MB
largest ChatGPT.exe:   ~406 MB

There was no obvious multi-GB runaway memory condition in this snapshot.

---

Windows Application event log check

Immediately after the problem I queried the last two hours for common application crash/hang events:

$start = (Get-Date).AddHours(-2)

Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = $start
} -ErrorAction SilentlyContinue |
Where-Object {
    $_.Id -in 1000,1001,1002 -and
    $_.Message -match 'ChatGPT|Codex|OpenAI'
} |
Select-Object TimeCreated, Id, ProviderName, Message |
Format-List

Result:

<no matching events>

I repeated the query and again received no matching entries.

Therefore, for these incidents, Windows did not produce an Event ID 1000/1001/1002 entry matching ChatGPT/Codex/OpenAI.

This is consistent with the main desktop process surviving while its child app-server terminates, rather than a conventional ChatGPT.exe access violation or application hang.

---

MSIX package state

Checked with:

Get-AppxPackage OpenAI.Codex |
    Select Name, Version, Status, InstallLocation

Result:

Name         : OpenAI.Codex
Version      : 26.825.6671.0
Status       : Ok
InstallLocation:
C:\Program Files\WindowsApps\OpenAI.Codex_26.825.6671.0_x64__2p2nqsd0c76g0

No package error is reported by AppX.

---

SQLite diagnostic database check

The Codex diagnostics database currently has:

logs_2.sqlite       63.89 MB
logs_2.sqlite-wal    4.26 MB
logs_2.sqlite-shm    0.03 MB

Command used:

$db = "$HOME\.codex\logs_2.sqlite"

Get-Item `
    $db,
    "$db-wal",
    "$db-shm" `
    -ErrorAction SilentlyContinue |
Select-Object Name,
              @{N='Size_MB';E={[math]::Round($_.Length / 1MB,2)}},
              LastWriteTime,
              FullName |
Format-Table -AutoSize

I then opened the database read-only with Python's standard sqlite3 module and ran:

PRAGMA quick_check;

Result:

DATABASE: C:\Users\<redacted>\.codex\logs_2.sqlite
QUICK CHECK: ok

So SQLite structural integrity currently passes.

I understand that PRAGMA quick_check = ok does not prove that higher-level rollout/thread state is logically consistent; it only rules out detectable SQLite structural corruption.

I have therefore not deleted, vacuumed, reset, or rebuilt this database.

---

Desktop log behavior

Desktop logs are under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\
LocalCache\Local\Codex\Logs\

When I initially enumerated the newest files, the three 2026-09-01 log files reported Length = 0.

Later, reading/filtering the current t0 log returned the failure/recovery entries quoted above.

I did not intentionally modify these files. Mentioning this only in case logging/buffering behavior is relevant.

---

One additional recovery race observed

During an Aug 30 recovery sequence, the frontend issued an MCP request before app-server recovery had fully completed:

Request failed
error={"code":-32000,"message":"Codex app-server is not available"}
failureReason=remote_unavailable
method=mcpServerStatus/list

Immediately afterward:

app_server_restart_recovery_done
resumedCurrentConversation=true

This looks like a secondary transient consequence of backend replacement rather than the primary termination.

---

What I have NOT done

Because the evidence points to an unexpected child app-server termination rather than obvious package/database corruption, I have intentionally not yet:

• deleted ~/.codex
• deleted logs_2.sqlite
• reset the Windows app
• manually modified files under WindowsApps
• reinstalled Windows
• replaced runtimes
• modified security/Defender settings
• modified the bundled codex.exe

I wanted to preserve the failing state and diagnostics before taking destructive troubleshooting steps.

---

Expected behavior

The app-managed codex.exe app-server should remain alive for the lifetime of the host/session unless a shutdown/restart is intentionally requested.

Normal tool execution should not result in the app-server receiving/ending with:

0xC000013A / STATUS_CONTROL_C_EXIT

If an app-server unexpectedly dies, the desktop application's recovery path should ideally recover transparently rather than presenting a fatal "ChatGPT hit a snag" screen.

Recovery should also avoid leaving persisted tool calls without corresponding outputs.

---

Actual behavior

Observed repeatedly:

ChatGPT.exe main process remains alive
        |
        v
codex.exe app-server terminates
exit=3221225786 / 0xC000013A
classifiedAsExpected=false
        |
        v
stdio AppServerConnection closes
        |
        v
fatal_error_broadcasted
        |
        v
"ChatGPT hit a snag"
        |
        v
desktop launches/reconnects app-server
        |
        v
app_server_restart_recovery_done
resumedCurrentConversation=true

---

Reproduction

I do not yet have a single deterministic minimal user action that reproduces the failure 100% of the time.

However, it has occurred repeatedly during normal use of the unified Windows desktop application and has reproduced across multiple backend generations and on separate dates.

The diagnostic signature has been stable:

code=3221225786
signal=null
classifiedAsExpected=false
cause=transport_closed
fatal_error_broadcasted

If maintainers need a more targeted experiment, specific logging, ProcMon capture, process-creation/termination tracing, ETW/WPR capture, Crashpad/Sentry artifact, or another non-destructive diagnostic, I can reproduce and collect it.

---

Current conclusion from local diagnostics

Confirmed locally:

• MSIX package exists and AppX reports Status = Ok
• app-managed codex.exe exists and successfully starts in app-server mode
• main ChatGPT.exe survives the incident
• renderer/GPU/network/storage child processes were present and responding
• app-server unexpectedly exits with 3221225786 / 0xC000013A
• desktop classifies the exit as unexpected
• fatal_error_broadcasted is emitted
• app-server is subsequently restarted/reconnected
• conversation recovery succeeds
• no matching Windows Application event 1000/1001/1002 was found
• SQLite PRAGMA quick_check returns ok
• no obvious runaway RAM usage was present in the captured process snapshot
• same backend termination signature occurred multiple times

Not established:

• what process/component delivers the console-control termination
• whether missing custom-tool outputs are a cause or an aftermath of earlier backend interruptions
• whether a specific tool/plugin/browser operation is the trigger

---

Possibly related existing issues

The failure signature appears closely related to:

• #36778 — Windows desktop app-server repeatedly killed with 0xC000013A
• #40231 — Windows regression: app-server killed with STATUS_CONTROL_C_EXIT during command execution
• #41418 — repeated 3221225786 / 0xC000013A app-server termination in recent desktop builds

My report adds a reproduction on:

Microsoft Windows NT 10.0.26200.0 x64
MSIX package: 26.825.6671.0
About dialog: 26.825.51511

If this is the same root cause as one of those issues, please feel free to close this as a duplicate and use the diagnostic data here as an additional reproduction on the newer build.

---

Privacy note

The log excerpts above have only been sanitized to remove:

• Windows username/path identity
• conversation IDs
• custom tool call IDs
• pipe UUIDs
• prompt/conversation contents

Exit codes, timestamps, process relationships, application versions, error types, state transitions, and diagnostic semantics have not otherwise been intentionally altered.

Start with the AppServerConnection logs and the codex.exe app-server entry point, then reproduce the Windows stdio termination using the reported exit code 0xC000013A. Compare the repeated failure and restart/recovery sequences, including the missing custom tool outputs. Done means identifying a supported cause or reliable reproduction and defining a fix or recovery behavior that prevents the repeated fatal-error interruption.