Cursor CLI: clicking a URL in the agent transcript does not open the system browser

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

In an interactive Cursor Agent CLI session, HTTP(S) links in the transcript cannot be opened in the system browser. Clicking a URL does nothing. There is no /open (or
similar) command, and the agent has no Browser pane/tool like Cursor Desktop.

The CLI’s only browser code is open-browser.ts, used for agent login. It calls xdg-open and ignores $BROWSER. Conversation links never go through that path. The TUI owns
the mouse, so the terminal’s Ctrl+click / OSC 8 handler also never runs.

This is a CLI product gap, not an OS default-browser misconfiguration. On this machine xdg-open and $BROWSER=omarchy-launch-browser both work from a normal shell.

Steps to Reproduce

  1. On Linux, install Cursor CLI and run agent in a terminal (Wayland session, working default browser).
  2. Confirm the system opener works: xdg-open ‘https://example.com’ (or $BROWSER ‘https://example.com’).
  3. In the same session, have the agent print a normal https:// URL (docs, GitHub issue, etc.).
  4. Click the URL, or Ctrl+click it, or ask the agent to “open this link in the browser” as if it had the Desktop Browser tool.

Expected Behavior

Clicking (or a dedicated /open ) should open the link in the system browser via xdg-open, and on Linux it should honor $BROWSER when set. Optionally emit OSC 8
hyperlinks so the terminal can open them if the TUI is not capturing the mouse.

Operating System

Linux

Version Information

• Cursor CLI: 2026.09.10-fd3934a (agent / cursor-agent)
• Desktop IDE: not installed on this machine
• Default browser: Zen (zen.desktop); $BROWSER=omarchy-launch-browser

For AI issues: which model did you use?

Grok 4.6 (Cursor Agent CLI)

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @jean-humann, thanks for the report.

A quick clarification on how this works today: the CLI already emits the URLs in the agent’s responses (and markdown links) as terminal hyperlinks, and it does not take over the mouse. The click itself is handled by your terminal emulator, not by the CLI, so it follows your terminal’s own link gesture and opener settings.

To pin down why clicks do nothing on your machine, could you try the following?

  1. Tell us which terminal emulator you are using (Ghostty, Alacritty, kitty, foot, etc.) and whether cursor-agent is running inside tmux, zellij, or screen.

  2. In a plain shell (not inside cursor-agent), run:

    printf '\e]8;;https://example.com\aClick me\e]8;;\a\n'

  3. Hover over “Click me” and click it the way your terminal expects (Ghostty and several others need Ctrl+click, kitty uses its prefix key, Alacritty a plain click on hover). Does https://example.com open?

  4. If step 3 does nothing, then the terminal (or tmux, which needs version 3.4 or newer to pass hyperlinks through) is not opening hyperlinks, and that is where to look.

  5. If step 3 works, start cursor-agent and ask: “Reply with the plain text https://example.com on its own line, not in backticks or a code block.” Then use the same click gesture on it.

One thing to watch for: URLs inside backticks, fenced code blocks, or command output are shown as code, not links, so make sure the URL is plain text in the agent’s reply.

Let us know what happens at steps 3 and 5, and which terminal you are on, and we will take it from there!

7

Thanks Colin. Follow-up from the original report, after checking this on the same Omarchy machine.

Terminal: foot 1.28 (Wayland). The agent session is foot --app-id=org.omarchy.agent -e cursor-agent …. Not tmux, not Ghostty/Alacritty/kitty. Omarchy’s default terminal is foot; Ghostty is optional.

You’re right about the CLI: it already emits OSC 8 for markdown links and bare https:// URLs, and it does not enable mouse tracking. Conversation links never go through open-browser.ts (that path is still login-only and calls xdg-open, ignoring $BROWSER). /open launches Cursor Desktop, not a URL. URLs in backticks/code are not links.

I had the mouse-capture part wrong. Clicks are handled by the terminal.

The click tests don’t apply to foot. Foot does not open URLs on click or Ctrl+click (Ctrl+click is block-select). It uses Ctrl+Shift+O (URL mode + jump labels), then xdg-open. So “click does nothing” in the transcript is foot’s design, not the CLI eating the mouse. Ghostty on Omarchy is the opposite: Ctrl+click opens the link, which matches what you described.

Please don’t treat “click does nothing on Linux” as a hyperlink failure when the emulator is foot. Happy to treat the mouse-capture theory as closed.

What still looks like a CLI gap, if you want to keep it as a feature request: there is no /open-url, and relying on “the terminal’s link gesture” is a poor fit for Omarchy’s default (foot). Switching the Omarchy default terminal to Ghostty makes Ctrl+click work without any CLI change.