codex - 💡(How to fix) Fix Stop hook receives malformed JSON stdin on Windows with non-ASCII assistant message

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Error Message

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:

Root Cause

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.

Code Example

Unterminated string passed in.

---

{"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]...}

---

Stop hook (failed): hook returned invalid stop hook JSON output
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

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

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Stop hook receives malformed JSON stdin on Windows with non-ASCII assistant message