Windows: long input-messages in turn-complete notify payload silently break notify in codex exec

Open 💬 2 comments Opened Apr 17, 2026 by ericali-ptc
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Windows: long input-messages in turn-complete notify payload silently break notify in codex exec

Summary

On Windows, codex exec appears to silently fail when invoking notify for turn completion if the notify payload contains very large input-messages.

A short prompt works normally.
A long prompt also completes normally from the user's perspective, but the configured .cmd notify script is never invoked, and codex exec prints no error.

This looks specifically related to the turn-complete notify payload, not to launching codex exec itself.

Codex version

codex-cli 0.121.0

Platform

  • Windows 11 Pro 64-bit
  • OS version: 10.0.26200 (build 26200)
  • PowerShell: 5.1.26100.8115

Minimal reproduction

This repro avoids making the initial codex exec command line itself too long.

  1. Create a tiny notify script:
@echo off
>>D:\t\n.log echo invoked
exit /b 0
  1. Run a short prompt through stdin:
Get-Content -Raw .\prompt-short.txt | codex exec --skip-git-repo-check --json -C .\workspace-short -c "notify=['D:/t/n.cmd']" -
  1. Confirm that D:\t\n.log gets a new line.
  1. Run a long prompt through stdin in the same way:
Get-Content -Raw .\prompt-long.txt | codex exec --skip-git-repo-check --json -C .\workspace-long -c "notify=['D:/t/n.cmd']" -

In my repro:

  • prompt-short.txt was small and worked normally
  • prompt-long.txt was about 111,840 characters
  • the equivalent turn-complete notify JSON payload was about 112,132 characters

Important detail

The initial codex exec launch succeeds in both cases, because the prompt is provided through stdin rather than through the shell command line.

The failure happens later, when Codex invokes notify for turn completion.

From the observed behavior, the turn-complete notify payload appears to include the original input-messages, so a large stdin prompt becomes a large notify payload on Windows.

Actual behavior

  • Short prompt:
  • the notify script is invoked
  • codex exec exits 0
  • no stderr output
  • Long prompt:
  • the notify script is never invoked
  • codex exec still exits 0
  • no stderr output
  • the Codex session completes normally and returns the final answer

This suggests the problem is not the initial codex exec invocation, but the later notify invocation using a completion payload that includes large input-messages.

Expected behavior

One of these should happen:

  1. Codex should avoid passing large turn-complete payloads to Windows .cmd notify commands via argv.
  2. Codex should use stdin, a temp file, or another transport for large notify payloads.
  3. If notify process creation fails, Codex should emit an explicit warning or error instead of failing silently.

Additional evidence

On the same machine, I separately reproduced Windows command-line length failures by manually launching:

cmd.exe /d /s /c D:\t\n.cmd <very-long-arg>

Results:

  • 400 chars: script invoked
  • 8000 chars: script invoked
  • 10000 chars: cmd.exe starts, script is not invoked, stderr = The command line is too long.
  • 30000 chars: same as above
  • 40000 chars: process creation fails
  • 112132 chars: process creation fails

For 40000 and 112132, the inner exception is:

  • type: System.ComponentModel.Win32Exception
  • native error code: 206
  • message: The filename or extension is too long

This strongly suggests the silent Codex failure is hitting the same underlying Windows command-line length limitation.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18067
  • #17107
  • #17259

Powered by Codex Action

kutayilmaaz · 16 days ago

Additional reproduction from Codex Desktop on Windows

I can confirm the same Windows argv-size failure in the notify path, this time with the Computer Use helper automatically configured by Codex Desktop.

Environment
  • Codex Desktop: 26.803.10989.0
  • Bundled CLI: codex-cli 0.147.0-alpha.1.2
  • Platform: Windows x64
  • Computer Use helper: codex-computer-use.exe
Observed behavior

Codex Desktop configures the following legacy notify hook using the currently installed Computer Use runtime:

notify = [
  "%LOCALAPPDATA%\\OpenAI\\Codex\\runtimes\\cua_node\\<runtime-hash>\\bin\\node_modules\\@oai\\sky\\bin\\windows\\codex-computer-use.exe",
  "turn-ended"
]

The helper executable exists and is runnable, so this is not a missing-file or stale-path failure.

Across the most recent 48-hour log window, I found 49 exact hook failures across multiple unrelated threads:

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

Turns still complete because the hook failure is treated as non-fatal.

Recurrence after disabling the hook

Commenting out the active notify entry stops this failure path, but the workaround is not durable:

  1. The active notify line was commented out after earlier os error 206 failures.
  2. Codex Desktop later recreated config.toml during normal app/config activity.
  3. A new active notify entry appeared, pointing to the new Computer Use runtime hash.
  4. The same legacy_notify / os error 206 warnings resumed immediately afterward.

This appears adjacent to the config-rewrite behavior reported in #26190, although the failure here is specifically the oversized turn-complete payload described in this issue.

Expected behavior

One or more of the following would prevent the recurrence:

  1. Pass the turn-complete payload through stdin, a temporary file, or another IPC transport instead of argv.
  2. Bound or omit large input-messages fields from the Windows notify payload.
  3. Do not automatically restore the legacy notify hook after the user has explicitly disabled it.
  4. If process creation fails with Windows error 206, expose a clear diagnostic identifying the payload/command-line size.