[FEATURE] Add "Open with..." / "Reveal in OS" to chat panel link context menu

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When I right-click a markdown file link in the Claude Code VS Code extension chat panel, the only option is "Copy link". There is no way to:

• Open the file in an editor other than VS Code's built-in viewer (e.g., Typora, Obsidian)
• Reveal the file in the OS file manager (Windows Explorer / Finder)

This becomes a hard blocker for files with non-ASCII paths. I work with a Cyrillic-named knowledge base (e.g., шаблон-презентации.md). Clicking such links does nothing - the extension's internal path resolver fails on non-ASCII.
And because the context menu has no alternative "open" action, there is no escape hatch.

The same workflow also affects users who simply prefer an external Markdown editor over VS Code's viewer, regardless of character set.

Proposed Solution

Add one or both entries to the chat panel link right-click menu, alongside the existing "Copy link":

1. Reveal in File Explorer / Finder - opens the OS file manager with the file selected. Implementation: vscode.env.openExternal(Uri.file(folderPath)) or the built-in revealFileInOS VS Code command.
2. Open with... - invokes the OS "Open with" dialog so the user can pick any registered application.

Both bypass the internal markdown-link resolver by handing the path to the OS, so they work regardless of filename character set.

Alternative Solutions

• Current workaround: "Copy link" → open Typora → File → Open → paste → Enter. 5 actions instead of 1.
• Installed the official Typora VS Code extension (cweijan.vscode-typora), which adds "Open in Typora" to the Explorer sidebar and editor tab right-click menus. But VS Code extension API does not allow third-party extensions to inject menu items into another extension's webview, so Typora's extension cannot reach the Claude Code chat panel. This fix must come from Anthropic.
• Tested file:// URIs, percent-encoded paths, absolute paths, raw UTF-8 — all fail for non-ASCII filenames (detailed test matrix in #51489).

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Scenario: I maintain a Russian-language knowledge base for my project. File names are in Cyrillic by convention.

1. I ask Claude Code: "what did we decide about X?"
2. Claude responds and references a source: [source](affiliates/chats/2025-09-17_шаблон-презентации.md)
3. I right-click the link -> only option is "Copy link"
4. Left-click does nothing (non-ASCII path - see #51584, #51489)
5. To open the file I have to: copy path -> open Typora -> File -> Open -> paste -> Enter (5 actions)
6. Multiply by dozens of links per day - significant friction.

With "Reveal in File Explorer", step 5 becomes one right-click. With "Open with..." pointing to Typora, two clicks. Either is a 5× speedup over the current workaround - and unlike a resolver fix, it is a universal escape hatch for any filename.

Additional Context

Related existing issues — all sharing the same root cause (no escape hatch from the broken internal resolver):

• #51489 — non-ASCII (Chinese) markdown links unclickable; all URL formats tested, none work
• #51584 — Cyrillic paths in Desktop app, closed as not planned
• #25426 — Japanese paths not clickable
• #10846 — base bug, markdown links don't open files
• #27672 — Windows-specific follow-up to #10846
• #16056 — macOS variant

An "Open with..." / "Reveal in OS" option would let users work around all of these without Anthropic needing to fix the underlying resolver.