Stop hook receives malformed JSON stdin on Windows with non-ASCII assistant message

[kcrazy]

Environment

• Codex CLI: 0.132.0
• OS: Windows
• Shell: PowerShell
• Model: gpt-5.5
• Hook type: Stop
• Node.js: v24.14.0
• Hook target in this setup: oh-my-codex v0.18.0

Summary

On Windows, Codex sometimes invokes a Stop hook with malformed JSON on stdin. The JSON is already invalid before the hook implementation runs.

This is related to, but distinct from, #18887. That issue is about Codex's error reporting for invalid Stop hook output. This report is about the input payload sent by Codex to the Stop hook being malformed before the hook can parse it.

Observed behavior

A local PowerShell wrapper captured the raw stdin before passing it to the hook process. The captured payload starts as normal JSON and includes fields like:

• session_id
• turn_id
• transcript_path
• cwd
• hook_event_name: "Stop"
• model
• permission_mode
• stop_hook_active
• last_assistant_message

But last_assistant_message contains mojibake/non-ASCII assistant output and the JSON string is not closed before the final }.

PowerShell parsing fails with:

Unterminated string passed in.

Node parsing also fails with an unterminated string error when the same captured stdin is replayed.

A sanitized shape of the malformed payload looks like:

{"session_id":"...","turn_id":"...","transcript_path":"...","cwd":"...","hook_event_name":"Stop","model":"gpt-5.5","permission_mode":"default","stop_hook_active":false,"last_assistant_message":"[mojibake/truncated non-ASCII assistant text]...}

Notice that last_assistant_message is not terminated as a JSON string.

Expected behavior

Codex should always serialize hook stdin as valid JSON, regardless of message language, encoding, or truncation.

Impact

Stop hooks that parse stdin fail before hook logic can run. In my case this eventually surfaced in the Codex UI as:

Stop hook (failed): hook returned invalid stop hook JSON output

The secondary UI error happened because the downstream hook returned a diagnostic object that is not accepted by the Stop output schema. However, the root issue is that the stdin payload from Codex was already malformed.

Additional notes

• Normal Stop hook payloads with small/ASCII last_assistant_message parse successfully and return {}.
• A different Stop payload with last_assistant_message containing a short escaped JSON string also parses successfully.
• The failure correlates with Chinese/non-ASCII assistant output becoming mojibake and being truncated inside last_assistant_message.
• I can provide a redacted raw capture if needed, but I avoided posting the full captured conversation content in this issue.

[kcrazy]

Additional evidence: the same malformed-stdin problem also happens for UserPromptSubmit hooks on the same Windows setup.

Observed UI message:

UserPromptSubmit hook (failed)
error: hook returned invalid user prompt submit JSON output

Local OMX hook log entries show the hook process fails before it can identify the event:

native_hook_stdin_parse_error
hook_event_name: Unknown
Unterminated string in JSON at position 379 / 720 / 374 / 468

I checked the embedded Codex schema for user-prompt-submit.command.output: hookSpecificOutput.hookEventName must be one of the known hook event names. When the hook receives malformed stdin, the downstream hook emits a diagnostic JSON object with hookSpecificOutput.hookEventName: "Unknown", so Codex rejects that stdout and displays the secondary "invalid user prompt submit JSON output" message.

Minimal local control test: feeding the same hook a valid UserPromptSubmit JSON payload with a Chinese prompt succeeds. The hook returns valid JSON with:

{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"..."}}

So the hook can handle a valid Chinese prompt payload. The failure path is triggered when the stdin JSON supplied by Codex is already malformed/truncated before hook logic runs.

This broadens the original report: the malformed JSON serialization is not limited to Stop.last_assistant_message; it can also affect UserPromptSubmit.prompt.