[BUG] IDE extension: markdown file links with non-ASCII (Korean) paths render but do nothing on click

Summary

In the IDE extension (tested in Cursor), markdown file links emitted by Claude are rendered as clickable links, but clicking does nothing when the path contains non-ASCII characters (e.g. Korean). Pure-ASCII paths open correctly.

Our repository uses Korean directory and file names throughout (docs/세션/...), so effectively none of the file links Claude produces are clickable.

Environment

• Extension: anthropic.claude-code-2.1.226-darwin-arm64 (installed in Cursor)
• OS: macOS 15 (darwin 24.6.0), arm64
• Filesystem: APFS, filenames stored in NFC (verified with unicodedata.is_normalized)

Steps to reproduce

1. Open a workspace containing a file whose path includes non-ASCII characters, e.g. docs/세션/26년Q3일정/메시지_정규20_변경일정_팀공유.md
2. Have Claude emit a markdown link to that file: [label](docs/세션/26년Q3일정/메시지_정규20_변경일정_팀공유.md)
3. Click the rendered link

Expected

The file opens in the editor, same as for ASCII paths.

Actual

The link renders in blue/clickable style, but clicking produces no action at all — no file opens, no error, no visible feedback.

Variants tested

| # | Link target | Result |
|:-:|---|---|
| A | Korean directory + ASCII filename — docs/세션/26년Q3일정/26Q3_weekly_table.md | ❌ nothing |
| B | Fully ASCII path — CLAUDE.md | ✅ opens |
| C | Korean path, as-is | ❌ nothing |
| D | Korean path, percent-encoded | ❌ nothing |
| E | Absolute Korean path | ❌ nothing |
| F | file:// URI, percent-encoded | ❌ nothing |
| G | vscode://file/... URI | ❌ nothing |

Any non-ASCII character anywhere in the path is enough to break it. Percent-encoding does not help.

Notes from a quick look at the shipped bundle

• The extension-side handler looks encoding-agnostic and would open these paths fine if it received the request:

``js
openFile(e,t){ let r = path.isAbsolute(e) ? e : path.join(this.cwd, e); ...
vscode.window.showTextDocument(vscode.Uri.file(r)) }
``

• The editor itself handles the same Korean paths without any problem (opening them from the explorer / quick open works).

That suggests the open_file request is never dispatched from the webview for non-ASCII hrefs, rather than the failure being on the extension host side. I could not pinpoint the exact check in the minified webview/index.js bundle, so this part is inference rather than a confirmed root cause.

Workaround

Opening via the cursor / code CLI works:

cursor "docs/세션/26년Q3일정/메시지_정규20_변경일정_팀공유.md"