Conversation search Cmd+F has Unicode tokenization bug — emoji and short CJK strings unfindable

The Cmd+F search within a conversation fails to match 2-character CJK strings (Chinese / Japanese kanji / Korean Hangul). 3+ character CJK strings, all ASCII, Cyrillic, Thai, and Arabic match correctly. Emoji also fail.

Environment

• Claude Code desktop
• Model: Opus 4.7 1M context, Max plan
• macOS
• Long conversation (~150+ messages)

Test matrix

Search a string that visibly exists in the conversation:

| String | Length | Script | Result |
|---|---|---|---|
| hello | 5 | ASCII | ✅ matches |
| 问题 | 2 | Chinese | ❌ 0/0 |
| 日本 | 2 | Japanese kanji | ❌ 0/0 |
| 사람 | 2 | Korean | ❌ 0/0 |
| 컴퓨터 | 3 | Korean | ✅ matches |
| こんにちは | 5 | Japanese hiragana | ✅ matches |
| 안녕하세요 | 5 | Korean | ✅ matches |
| 今日は天気がいい | 10 | Japanese mixed | ✅ matches |
| Привет | 6 | Cyrillic | ✅ matches |
| สวัสดี | 6 | Thai | ✅ matches |
| مرحبا | 5 | Arabic | ✅ matches |
| ⭐️ | 1 grapheme | Emoji | ❌ 0/0 |

Pattern

• CJK strings ≥3 characters: match
• CJK strings ≤2 characters: fail
• Emoji: fail (likely surrogate pair / grapheme cluster handling)
• Non-CJK non-Latin (Cyrillic, Thai, Arabic): match at all lengths tested

Hypothesis

The search index likely uses n-gram with N=3 for CJK. Strings shorter than N can't be tokenized into any bucket, hence no match. Emoji likely fail because they're encoded as UTF-16 surrogate pairs and the tokenizer splits on code units instead of grapheme clusters.

Expected

All visible text in the conversation should be findable, regardless of script or length.

Workaround

For short CJK terms, search with one extra adjacent character to reach 3 characters (e.g., 사람들 instead of 사람).

Possibly related: closed issue #23911 (CJK characters not handled in @ autocomplete) — suggests a systemic issue with CJK text processing in the desktop app.