# My Claude Code hook silently ate every Korean character, and it took me an hour to figure out why

> Source: <https://dev.to/codingjhj/my-claude-code-hook-silently-ate-every-korean-character-and-it-took-me-an-hour-to-figure-out-why-3ii4>
> Published: 2026-06-06 03:48:06+00:00

I spent an hour last week debugging a hook that wasn't broken.

Here's the setup: I run Claude Code on Windows, and I'd written a little `UserPromptSubmit`

hook in PowerShell — a keyword router that reads my prompt and, if it sees something like `mcp 서버`

or `코드 리뷰`

, injects a hint so Claude pulls up the right skill. Half my prompts are in Korean, so a bunch of the regex patterns had Korean in them.

It worked perfectly for the English rules. The Korean ones? Dead. No match, no error, no log line. The script ran, exited 0, and just... did nothing for half my inputs.

I did all the dumb things first. Echoed the prompt — looked fine. Tested the regex in a PowerShell console — matched fine. Re-read the JSON parsing five times. Added `Write-Host`

debugging everywhere. Nothing.

The actual problem had nothing to do with my code. It was the **file encoding**.

Windows PowerShell 5.1 (the default `powershell.exe`

, not `pwsh`

) does not assume UTF-8 when it reads a `.ps1`

file. If there's no byte-order mark, it falls back to the legacy system code page. So my script — saved as plain UTF-8 by my editor — got its Korean bytes reinterpreted as garbage *at parse time*, before a single line ran. The regex literal that was supposed to be `코드.?리뷰`

became mojibake, which of course never matches anything real. And because it's a parse-level reinterpretation, you don't get an error. You get silence.

The fix is one line, once you know:

``` php
function Add-Bom($path) {
  $text = [System.IO.File]::ReadAllText($path)
  $enc  = New-Object System.Text.UTF8Encoding $true   # $true = write the BOM
  [System.IO.File]::WriteAllText($path, $text, $enc)
}
Add-Bom "$env:USERPROFILE\.claude\skill-router.ps1"
```

Re-save with a BOM and everything lights up. Pure-ASCII scripts don't care, which is exactly why every example you find online "works" — almost all of them are bash on macOS, and the handful of PowerShell ones never have a non-ASCII character to trip over.

That bug annoyed me enough that I went and cleaned up my whole Claude Code setup so I'd never have to rediscover this stuff. A few things that were worth keeping:

`rm -rf /`

, `DROP TABLE`

, `git push --force`

, `taskkill`

, a disk format, etc. It doesn't hard-block — it injects a "show this to the user and confirm first" instruction. Saved me from a `--hard`

reset I didn't mean to approve.`chcp 65001`

+ a temp file + stdin redirect — don't ask how long that took either).I put it all up here, MIT, free: [https://github.com/coding-jhj/claude-pwsh-kit](https://github.com/coding-jhj/claude-pwsh-kit)

It's not magic and it won't make Claude smarter. It's plumbing — guardrails, routing, and a setup guide that tells you about the BOM thing on page one so you don't lose the hour I lost.

If you're on Windows and your hooks are misbehaving in ways that make no sense, check your encoding before you check your logic. And if you've hit other PowerShell-specific Claude Code papercuts, tell me — I'd rather fix them in the repo than rediscover them at 1am.