Let users allow extra URL schemes for links in chat (zotero:, obsidian:, cursor:, …)

[kevinbpatel]

Note

Written by Claude (Claude Code, Opus 5.5) for @kevinbpatel. Claude looked into why a link in chat wouldn't open, read the shipped client bundle and main @ 3ff5b3c, and drafted this. Kevin asked for it to be posted.

Problem

Agents often write links to desktop apps: a reference manager item, a note, an editor location, a task, a ticket. Users can't add a URL scheme to what T3 Code will open, so all of these links do nothing.

Two layers filter links, and both use a fixed list:

• Renderer. markdownUrlTransform in apps/web/src/components/ChatMarkdown.tsx allows T3's own hrefs (citations, context, thread links, file paths), then calls react-markdown's defaultUrlTransform. That allows only http, https, irc, ircs, mailto and xmpp. Any other scheme gets an empty href. The text still looks like a link, but clicking it does nothing and shows no error.
• Desktop. parseSafeExternalUrl in apps/desktop/src/electron/ElectronShell.ts passes only http:/https: and the remote editor links (vscode://vscode-remote/ssh-remote+…, zed://ssh/…, jetbrains://gateway/…) to shell.openExternal.

The OS handlers work. The same URL opens the right app from a shell (open / xdg-open), a browser or a terminal.

Prior requests

The same root cause keeps coming back, each time for different apps:

• fix(markdown): make known app deep links clickable #15722 (closed, not merged): hard-coded allowlist for linear:, slack:, notion:, obsidian:
• [Bug]: cursor:// and vscode:// links in chat do nothing when clicked #16822 (open): cursor:// and vscode:// file links do nothing
• [Bug]: Preview browser cannot open native apps via custom-scheme deep links #16251 (closed): custom-scheme deep links dropped silently in the preview browser

A built-in list will always miss some app: Zotero (zotero://select/…, zotero://open-pdf/…), DEVONthink (x-devonthink-item://), Things (things:///), Bear, Logseq, OmniFocus, Raycast, internal company tools, and so on. A built-in list also makes maintainers decide which apps qualify.

Proposal

Add a user setting for extra URL schemes that links in chat may open, for example Settings → Integrations → "Allowed link schemes", with a list such as zotero, obsidian, things.

• Off by default. With the list empty, behavior is the same as today.
• Both layers read the same list. The renderer keeps the href. The desktop shell hands the URL to shell.openExternal. Mobile passes it to the native URL handler. Links open on the client device, which already happens for http links.
• Some schemes can never be added, e.g. javascript, data, vbscript, file, blob, about, chrome, devtools, and probably smb/ms-* on Windows. Raw HTML should stay sanitized as it is now.
• Optional: confirm the first time each scheme is opened ("Open links to Zotero? Always / Once / Cancel"). The answer could fill in the list, so most users never edit it by hand.
• Optional: show a short notice when a link was blocked (zotero: links are blocked. Allow?), so the click isn't silently dropped.

That resolves #16822 and the cases behind #15722 without a hard-coded list of apps. A small built-in default set could still ship if maintainers want one.

Current workaround

Point the link at a small http page that redirects to the custom scheme (location.href = "zotero://…"). T3 opens it in the system browser, which then hands off to the app. This works, but each user has to run a small server that every machine they click from can reach, and it adds a browser tab and a confirmation prompt on every click.

Environment

T3 Code nightly 0.1.1-nightly.20261018.3315. Server on Linux, desktop client on macOS, Claude Code provider.

---

🤖 Generated with Claude Code

[noelcserepy]

Note

Written by Claude (Claude Code, Opus 5.5) for @noelcserepy.

Another case: linear:. My agents link Linear issues all day. A linear:// link renders as plain text in chat, for the reason this post gives.

The Linear desktop app (1.32.4, macOS) registers linear as its protocol. It strips linear:// and an optional linear.app/, then opens the rest as a Linear path in the open window. open linear://<workspace>/issue/TODO-14 from a terminal opens the issue straight in the app.

Today's workaround is Linear's "open links in desktop app" setting with plain https://linear.app/... links. That works, but every click still opens a browser tab before the app takes over.

A user setting as proposed here would cover this with no Linear-specific code. +1 to the optional first-use confirmation.

Environment: T3 Code Nightly 0.1.1-nightly.20261020.3411, macOS 26.6.2.

[wcass77]

Thanks for all the work on T3 Code. I’d appreciate the general, user-controlled approach proposed here. Beyond common apps like Obsidian and Slack, there’s a long tail of specialist apps and private tools whose links would be useful in chat. Supporting each through a separate carve-out seems difficult to keep up with.

Spark is one example from my own workflow: its private email links open the correct message when launched directly on macOS, but are inert in T3 chat. HTTPS fallbacks work, though they add a browser step. Other users will have similar needs for different apps.

An assisted source investigation found separate checks in Markdown rendering, desktop external opening, and mobile link handling, so a renderer-only change wouldn’t cover every client.

Perhaps a small initial version could offer:

• Open once / Always allow this scheme / Cancel, with revocable permissions.
• Opening on the client device, with a helpful message if no handler is available.
• Preservation of encoded destinations, keeping private tokens out of diagnostics.
• Existing protections for dangerous schemes and current file/editor behavior.

Would this direction fit your plans? I’d be happy to contribute synthetic reproduction cases and help test macOS/iOS behavior if useful. Thanks again for considering it.

[TaylorMerritt]

Another case for the user-configurable list: I use a small app I built myself, Sidecar, which registers sidecar://. Its links open correctly from the terminal (open "sidecar://…"), but in T3 chat they render with no link and the right-click menu has no "Copy link", so there's no workaround inside the app.

No hard-coded list will ever include a private tool like this, so the narrow fixes (#23486 for editors, #31386 for Obsidian) can't cover it. I'd be happy with either:

• an "Allowed link schemes" setting, empty by default, enforced by the desktop app, or
• an "Open in Sidecar?" confirmation that shows the full URL for any scheme not on the list, with an option to always allow that scheme.

Opt-in per user seems like the right default, since agent output can contain links an attacker planted.

Platform: macOS 26.6.2, T3 Code Nightly desktop 0.1.8-nightly.20261106.4275