Codex Desktop: support clickable custom URI scheme links in chat (e.g. obsidian://)

Open 💬 2 comments Opened Jun 2, 2026 by bdteo

Summary

Codex Desktop should preserve clickable Markdown links for custom URI schemes such as obsidian:// instead of rendering them as plain text after the final message render.

In a desktop Codex chat, I tested several Obsidian deep-link formats. The links appeared clickable briefly while the assistant message was streaming, but after the message finished rendering they became non-clickable/plain text. A normal local file link still rendered as a clickable file card.

Why this matters

Agents often produce links to local notes, work logs, specs, and evidence. Many users keep those in tools that expose deep links through custom URI schemes, for example:

obsidian://open?... for Obsidian notes
vscode://... / cursor://... for editor links
x-devonthink-item://..., hook://..., bear://..., etc.

For local-agent workflows, these links are useful and low-friction: the model can write a worknote or doc and then provide a direct "open in the right app" link.

Reproduction

On Codex Desktop for macOS:

Ask the assistant to print a Markdown link like:

``markdown [Open today's worknote in Obsidian](obsidian://open?path=%2FUsers%2Fboris%2FLocal%2FBoris%2FJournal%2FWork%2F2026-06-02.md)``

Also test raw/autolink forms:

``text obsidian://open?path=%2FUsers%2Fboris%2FLocal%2FBoris%2FJournal%2FWork%2F2026-06-02.md <obsidian://open?path=%2FUsers%2Fboris%2FLocal%2FBoris%2FJournal%2FWork%2F2026-06-02.md> obsidian:///Users/boris/Local/Boris/Journal/Work/2026-06-02.md obsidian://open?vault=Boris&file=Journal%2FWork%2F2026-06-02.md``

Observe that, after final render, the obsidian:// links are not clickable. The Markdown link text renders as plain text without a working link target.
As a control, a normal local file link like [Local file link](/Users/boris/Local/Boris/Journal/Work/2026-06-02.md) renders as a clickable local file card.
As a second control, running this in Terminal works and opens the note in Obsidian:

``bash open 'obsidian://open?path=%2FUsers%2Fboris%2FLocal%2FBoris%2FJournal%2FWork%2F2026-06-02.md'``

Expected behavior

Codex Desktop should allow Markdown links with recognized or user-approved custom URI schemes to remain clickable, and route them through the OS URL handler.

At minimum, it would be useful to support a safe allowlist or confirmation flow for custom protocols, similar to how browsers ask before opening external apps.

Actual behavior

The custom URI link does not remain clickable after final render. The OS can open the URI successfully, so the issue appears to be in the Desktop chat renderer/sanitizer rather than in macOS or Obsidian.

Environment

App: Codex Desktop
OS: macOS
Scheme tested: obsidian://
Repository local control: normal /Users/.../*.md file link rendered as clickable

View original on GitHub ↗

2 Comments

markse123 · 2 months ago

Feature request: support custom URI scheme deep links in Codex Desktop

Related upstream issue: https://github.com/openai/codex/issues/25787

Adding another affected custom URI scheme: webexteams://.

Privacy-safe examples of the kind of links Codex should preserve:

[Open related Webex space](webexteams://im?space=<space-id>)
[Open related Webex message](webexteams://im?space=<space-id>&message=<message-id>)

Use case: Codex agents often summarize investigation or coordination work and need to hand the user back to the relevant collaboration app context. For Webex workflows, that context is commonly a webexteams:// space or message deep link. When Codex renders these as plain text, strips the link target, or rewrites the target through an internal app URL, the user has to manually reconstruct or paste the link elsewhere.

Expected behavior: Codex Desktop should preserve custom URI scheme Markdown link targets and route them through the OS handler after an appropriate confirmation or user-managed allowlist. The behavior should be scheme-agnostic enough to support enterprise collaboration tools, not only note-taking/editor schemes.

eastLaugh · 2 days ago

A concrete developer workflow affected by this limitation is multi-file code-path tracing in Codex Desktop.

When Codex explains a call chain, it may produce a sequence such as:

handler.go:120
service.go:87
repository.go:44
client.go:201

The current absolute-path links are routed into Codex Desktop's built-in file viewer. For users whose working editor is VS Code, that viewer is not an adequate replacement for normal editor navigation: tab management, symbol navigation, search, back/forward history, split views, and repository context are all lost or substantially worse.

A link such as:

[service.go:87](vscode://file/Users/example/project/service.go:87)

would let the explanation function as an actual navigable call graph. Today the assistant may emit the URI as plain text, but it cannot remain a clickable Markdown link, forcing the user to copy commands or manually locate every file and line.

This is more than generic custom-protocol support: blocking editor URI schemes creates product lock-in toward the built-in viewer and materially degrades common local-agent workflows. A good solution could be either:

allow user-approved custom URI schemes with an external-app confirmation;
add an “Open file links in” preference with VS Code/Cursor/custom handler options; or
provide a per-link “Open in external editor” action while preserving exact line/column information.

Environment: Codex Desktop on macOS. Reproduced with vscode://file/...; ordinary absolute-path Markdown links remain clickable but open through the Codex-controlled local-file path.