Desktop app: Ctrl+F page search doesn't match Japanese text (only romaji/ASCII)

Same defect with Traditional Chinese, on Windows 11.

Repro:

1. Open a session transcript containing Traditional Chinese text.
2. Ctrl+F, type a Chinese term plainly visible on screen (e.g. 交接).
3. No matches. An ASCII term in the same transcript matches fine.

Scope-narrowing data point: the cross-session transcript search exposed by the
desktop app's session-management MCP tool (search_session_transcripts) handles
CJK correctly -- searching 交接 returns correct hits with correctly-positioned
snippets, while handoff returns hits from the same sessions. So the stored
content and the cross-session index are both fine; the defect is isolated to the
in-page (Ctrl+F) matcher in the desktop UI.

Given that split, a plausible cause is that the in-page matcher does
word-boundary or whitespace-tokenized matching (e.g. a \b-anchored regex, or an
ASCII word splitter) rather than the plain case-insensitive substring match the
cross-session search uses. Word boundaries never fire between CJK characters, so
a whole run of CJK collapses into one token and only an exact full-token query
could hit. This affects Chinese, Japanese and Korean identically, so it should be
one matcher fix, not per-language handling.

Filling in the fields the bug template asks for, since this issue was opened
without it:

• Claude Code desktop app version: 1.46388.4
• Claude Code CLI version: 2.1.235
• Operating System: Windows 11 Pro (10.0.26200)
• Platform: Claude Desktop app on an Anthropic subscription (not Bedrock/Vertex)
• Terminal/Shell: N/A -- desktop app, not a terminal session
• Is this a regression? I don't know, but it has never worked in the ~2 months

I have been using the desktop app, so if it is a regression it predates that.

@bcherny could this get the bug label? It was filed without the bug template,
so it does not carry one, which keeps it out of the label:bug queries the
template itself points people at for dedupe.

Follow-up with controlled tests — this turns out not to be a CJK matching bug. The
in-page search simply doesn't run until the query is at least 3 characters long,
for any script. My earlier word-boundary hypothesis was wrong; please disregard it.

Page text: 今天來測試交接流程 and ABC交接123

| Query | Length | Result |
|---|---|---|
| 交接 | 2 | no match |
| AB | 2 | no match |
| 交接 (leading space) | 3 | match |
| 交接流 | 3 | match |
| ABC | 3 | match |
| 測試交接 (mid-run) | 4 | match |
| 今天來測試交接流程 | 9 | match |

Substring matching inside unbroken CJK runs works fine (測試交接 hits mid-sentence),
and a 2-character ASCII query fails just like a 2-character CJK one. So the only
problem is the minimum query length.

Why this reads as "CJK search is broken": a 3-character minimum rarely matters in
English, but a large share of Chinese and Japanese words are exactly 2 characters
(交接, 搜尋, 検索, 設定), and single-character queries are common too. The original
report ("only romaji works") fits: romanized terms are almost always longer than
2 characters.

Suggested fix: drop the minimum, or apply it only to ASCII-only queries, so any
query containing CJK characters searches from 1 character.

Same environment as my previous comment (desktop app 1.46388.4, Windows 11 Pro 10.0.26200).

One more data point on impact: there is no in-page workaround for 2-character CJK
queries.

• Padding with whitespace doesn't help — spaces are matched literally, so 交接 and

交接 find nothing inside 今天來測試交接流程.

• Extending the query with a neighbouring character requires already knowing what

surrounds the word, which is usually exactly what the user is searching to find.

So for Chinese/Japanese users the most common search, "where did this 2-character
term come up", can't be done with Ctrl+F at all. The only workaround I found is
asking Claude to run the cross-session transcript search, which returns snippets but
can't highlight or jump within the page.