[BUG] Cowork chat strips non-http(s) link hrefs, and "copy link address" then returns the page's own URL

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)

What's Wrong?

In Cowork chat on the desktop app, a markdown link whose href uses a non-http(s) scheme is rendered as link-styled text with its href stripped. The link looks live but does nothing.

The misleading part is what replaces the href. Right-clicking the link and choosing "copy link address" yields https://claude.ai/cowork/agent — the URL of the page itself — rather than the intended target or nothing at all. So the failure is not just silent, it hands back a plausible-looking wrong URL.

Concretely, an agent that emits [DOC-1](linear://linear.app/issue/DOC-1) produces text that is styled as a link, is not clickable, and copies as the Cowork page URL.

I originally assumed this was OS-level scheme routing failing to find a handler. It is not: the same linear:// URL routes correctly to the desktop app when opened from other macOS surfaces (terminal open, Spotlight, other apps). The href never leaves the chat renderer.

What Should Happen?

One of the following, in preference order:

1. Non-http(s) scheme links render as working links, at least for an allowlist of known-safe schemes.
2. If a scheme is deliberately not allowed, the link is rendered as plain text and "copy link address" is not offered — so it is visibly not a link.

What should not happen is the current third state: styled as a link, inert, and copying a URL that points somewhere else entirely.

Error Messages/Logs

No error is produced. The link renders, the click does nothing, and the copied
address silently resolves to the host page rather than the intended href.

Steps to Reproduce

1. Open a Cowork session in the desktop app.
2. Have the assistant emit a markdown link with a custom scheme, for example [open](linear://linear.app/issue/ABC-1). Any non-http(s) scheme reproduces it.
3. Click the rendered link. Nothing happens.
4. Right-click it and choose "copy link address". The clipboard contains https://claude.ai/cowork/agent.

Workaround in use: emit plain https:// links only. Those are clickable and copy correctly.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.34493.1 (the build currently installed on the affected machine).
The exact build in use on the day the behaviour was first observed was not recorded,
so this is the current version rather than a confirmed-affected one.

Platform

Claude Desktop app

Operating System

macOS 26.5.2 (build 25F84), Apple silicon

Terminal/Shell

Not applicable (desktop app chat, not a terminal session)

Additional Information

#76505 reports what looks like the same underlying renderer behaviour on a different
surface: the VS Code extension's chat webview passes assistant markdown through
react-markdown's default urlTransform, which blanks any href whose scheme is not
http(s), ircs, mailto or xmpp. That report is scoped to the extension and is
filed as an enhancement for the extension's own vscode:// links.

This report is separate because it is a different surface (Cowork chat on the desktop
app, not the VS Code extension) and because of the "copy link address" behaviour above,
which is a correctness problem rather than a missing feature: the user is handed a URL
that is not the one in the document. If both surfaces share a renderer, fixing them
together would presumably resolve both.

I have not verified which renderer Cowork chat uses, so the shared-cause link between
the two reports is an inference from identical observed symptoms, not something I
confirmed in the code.