PostToolUse hooks are not invoked when the tool's file path contains non-ASCII (e.g. Korean) characters (Windows)

Environment

• OS: Windows 11
• Claude Code: CLI (latest)
• Shell: PowerShell / Git Bash

Summary

On Windows, when a Write/Edit tool call targets a file whose path contains non-ASCII characters (reproduced with Korean — e.g. a directory or filename in Hangul), the configured PostToolUse hook is never executed. The same hook fires reliably for tool calls on ASCII-only paths within the same session. The failure is silent: no hook process start, no stdout/stderr, no error.

Expected

PostToolUse (matcher Edit|Write) fires for every Edit/Write regardless of whether the file path contains non-ASCII characters.

Actual

For non-ASCII tool-call paths the hook command is not spawned at all.

Reproduction (controlled experiment)

Configure a PostToolUse hook (matcher Edit|Write) that runs a small script. The script appends one JSON line to a log file as its very first action (inside try/except, so even malformed stdin still logs an entry). Then, in one session, edit/write several files and inspect the log:

| Tool-call target path | Non-ASCII in path | Hook logged an entry |
|---|---|---|
| some/ascii/dir/file.md (Write + Edit) | No | yes |
| some_ascii_script.py (Edit ×3) | No | yes |
| another_ascii_file.md (Write) | No | yes |
| <hangul-dir>/<hangul-name>.md (Write) | Yes (dir+name) | none |
| <hangul-dir>/ascii_name.md (Write) | Yes (dir) | none |
| ascii_dir/<hangul-name>.md (Write) | Yes (filename only) | none |

• ASCII paths: every one logged.
• Non-ASCII paths: none logged.
• An ASCII write issued immediately after the non-ASCII misses did log → the hook subsystem was still alive; firing did not die.
• The disambiguating case is the last row: a non-ASCII filename under an ASCII directory also failed → isolates the cause to non-ASCII characters in the path, not to any directory/content filtering.

The hook script is not at fault

Invoking the exact same hook command directly from the shell with a synthesized stdin payload whose file_path is the Korean path runs to completion correctly. So the script handles non-ASCII paths fine; the problem is that Claude Code does not invoke it for those tool calls.

Hypothesis

The harness likely fails to construct/dispatch the hook invocation (or evaluate the matcher) when the tool input path contains non-ASCII characters on Windows — plausibly a path encoding issue (cp949 vs UTF-8) in hook event construction.

Impact

Any PostToolUse automation keyed on files under non-ASCII directories silently does nothing, with no error. On non-English systems (very common: Korean/Japanese/Chinese directory names) this disables a broad class of file-event hook automation, and the silence makes it look like "hook ran, found nothing."