Codex App on Windows crashes after legacy_notify hits os error 206

Open 💬 2 comments Opened Jul 1, 2026 by adpena

What version of the Codex App are you using?

26.623.11225.0

Observed installed package:

OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex App on Windows crashed to the full-screen "An error has occurred" page after an after_agent notification hook failed with Windows native error 206.

Exact error text from the crash screen:

An error has occurred
Codex crashed with the following error:

  (code=3221225786, signal=null).

Most recent error: {"timestamp":"2026-07-01T22:01:56.531371Z","level":"WARN","fields":{"message":"after_agent hook failed; continuing","turn_id":"e0e2450a-b919-449e-9490-2d5a1df228d7","hook_name":"legacy_notify","error":"The filename or extension is too long. (os error 206)"},"target":"codex_core::hook_runtime"}

This looks like the Desktop/App version of a Windows notify transport bug. A hook failure whose own log message says continuing should not be able to take down the Codex App control plane.

I searched before filing:

I did not find an exact existing issue for:

  • after_agent hook failed
  • hook_name="legacy_notify"
  • codex_core::hook_runtime
  • Codex App crash screen with code=3221225786

What steps can reproduce the bug?

The exact minimal repro is not fully isolated yet, but the observed path is:

  1. Use Codex App on Windows in a long-running, high-context coding thread.
  2. Let an agent turn complete after substantial prompt/context/history has accumulated.
  3. Codex attempts the legacy notify hook after the agent turn.
  4. The hook fails with Windows error 206:

``text
The filename or extension is too long. (os error 206)
``

  1. Instead of treating the hook failure as non-fatal, the Codex App crashes to the error screen with:

``text
code=3221225786, signal=null
target="codex_core::hook_runtime"
message="after_agent hook failed; continuing"
hook_name="legacy_notify"
``

This is consistent with the Windows command-line/path-length failure mode described in #18309, except here it is surfacing through Codex App / legacy_notify and crashing the app UI.

What is the expected behavior?

Codex should not crash because a notification hook fails.

Expected behavior:

  1. Do not pass large hook/notify payloads through Windows argv/path-sensitive process creation.
  2. Use stdin, a temp file, a bounded digest payload, or another Windows-safe transport for hook payloads.
  3. If a hook fails, report a non-fatal diagnostic and continue the session.
  4. Preserve the active thread, terminal/process state, tool state, and queued work.
  5. Keep the error visible enough for debugging without making the app unusable.

Additional information

This is part of a pattern of serious Windows Codex App stability failures during real coding work. In this same workstream, separate Codex crashes have cost significant time, tokens, and disrupted long-running build/proof work. These are not cosmetic issues: for a paid Pro workflow, losing agent continuity and having to spend time keeping the app alive is a major reliability problem.

I am disappointed by the Windows App stability compared with the macOS experience and compared with other desktop AI coding tools. The Windows app currently feels fragile under serious long-running engineering sessions, which makes it hard to use effectively on a Windows workstation.

The fix should be structural, not just better error wording: hook/notify execution should have a Windows-safe payload transport and hook failure isolation so a best-effort notification cannot crash the app control plane.

View original on GitHub ↗

2 Comments

aidawilliam41-ops · 1 month ago

Still reproducible in Codex App 26.707.3748.0 / codex-cli 0.144.0-alpha.4 on Windows.

In the current app process on 2026-07-10, codex_core::hook_runtime logged the same warning 5 times:

after_agent hook failed; continuing
hook_name=legacy_notify
error=The filename or extension is too long. (os error 206)

The app did not crash this time and the current process remains running. This suggests crash containment may have improved since 26.623.11225.0, but the underlying Windows notify transport bug remains: legacy_notify still hits error 206, so turn-completion notifications can be lost.

Please keep this issue open until the payload transport is Windows-safe (for example stdin, a temp file, or a bounded payload), or legacy_notify is retired.

seeghostsmarketing · 1 month ago

Reproduced again on 2026-07-14 with Codex App 26.707.9981.0 on Windows. After reconnect, the packaged app-server reported version 0.144.2.

Environment:

Microsoft Windows NT 10.0.26200.0
X64
PowerShell 7.6.3

The user-level config contains the app-managed Computer Use notifier:

notify = ["%LOCALAPPDATA%\\OpenAI\\Codex\\runtimes\\...\\codex-computer-use.exe", "turn-ended"]

Sanitized timeline from the Codex Desktop log:

2026-07-14T11:53:41.707218Z WARN
target=codex_core::hook_runtime
message="after_agent hook failed; continuing"
hook_name="legacy_notify"
turn_id="019f6075-36cc-7f53-9111-ecc56fa50e07"
error="The filename or extension is too long. (os error 206)"

2026-07-14T11:54:51.870Z
app_server_connection.closed
code=3221225786
signal=null
transport=stdio

2026-07-14T11:54:51.877Z
Codex CLI process exited
classifiedAsExpected=false

2026-07-14T11:54:51.878Z
fatal_error_broadcasted

2026-07-14T11:55:04.038Z
app-server initialize succeeded
currentVersion=0.144.2

The user saw the full-screen fatal error page during this event.

One diagnostic distinction may matter: decimal exit code 3221225786 is 0xC000013A (STATUS_CONTROL_C_EXIT). The hook warning preceded the process exit by about 70 seconds and explicitly says continuing. Therefore, these logs do not prove that error 206 directly terminated the app-server. They do prove that:

  1. legacy_notify still hits Windows error 206 in App 26.707.9981.0.
  2. The app-server later exited unexpectedly and the Desktop App displayed the most recent stderr warning as the apparent fatal reason.
  3. The UI can therefore misattribute a later process termination to a non-fatal hook warning.
  4. Recovery succeeded after a new app-server process was started, but the user still encountered the disruptive fatal error screen.

Please address both layers:

  • use a Windows-safe transport for notify payloads (stdin, temp file, or bounded payload);
  • keep notify/hook failures isolated and non-fatal;
  • distinguish the actual app-server termination cause from the last stderr warning in the crash UI;
  • recover without replacing the task with a full-screen fatal error page.