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

Open 💬 1 comment Opened Apr 17, 2026 by ericali-ptc

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 ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗