Chat panel strips URL fragments on plain click, but right-click -> Open in External Browser preserves them

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor for iOS

Describe the Bug

Chat panel strips URL fragments on plain click, but right-click → Open in External Browser preserves them

Summary

A markdown link in the agent/chat panel whose URL contains a fragment opens in the external browser with the #fragment stripped, landing at the top of the page instead of at the anchor.

Right-clicking the same link and choosing Open in External Browser preserves the fragment and lands correctly. So two click paths on the same link in the same panel disagree.

Steps to Reproduce

  1. Get the agent to emit a markdown link with a fragment in the chat panel, or paste one in. Any URL with an anchor works; a GitHub review comment is a realistic case:
    https://github.com/xxx/pull/123#discussion_r123
  2. Left-click the link.
  3. Look at Chrome’s address bar.

Expected: the URL retains #discussion_r123 and the page scrolls to that comment.

Actual: the address bar shows https://github.com/xxx/pull/123 with no fragment, and the page sits at the top. On a PR with dozens of comment threads the target is effectively unfindable.

  1. Now right-click the same link → Open in External Browser.

Actual: the fragment is preserved and the page lands on the comment. This is the divergence.

Expected Behavior

What I ruled out

The fragment loss is not the OS, the browser, or the destination site.

  • macOS open handoff preserves fragments. open "https://example.com/#cursorFragmentTest123" → Chrome’s address bar reads https://example.com/#cursorFragmentTest123.
  • The destination site is not rewriting the URL. open on the exact failing GitHub URL keeps the fragment, and I watched Chrome’s live URL for 26 seconds afterwards — it never dropped. (Worth stating because GitHub does drop hashes for review comments in some collapsed-thread states, which is a plausible-sounding false explanation. It isn’t what’s happening here.)
  • Same browser throughout. Chrome preserves the fragment on every path except a plain click in the chat panel.

Chrome’s live URL was read with:

osascript -e 'tell application "Google Chrome" to return URL of active tab of front window'

Why this matters

Fragment links are how you point someone at one item inside a large page. The common cases are GitHub review comments (…/pull/<n>#discussion_r<id> and …/pull/<n>/files#r<id>) and anchors in long docs. When an agent surfaces “here is the specific comment that needs your attention,” a plain click silently discards the precision and drops the reader at the top of the page — with no indication anything was lost.

It’s also a poor failure mode to diagnose. The natural assumption is that the destination site dropped the hash, so the time goes into investigating the wrong system.

Suggestion

Make the plain-click path hand the full URL, fragment included, to the external browser — the same way the right-click path already does. The right-click path working suggests the URL is intact at dispatch time and one of the two handlers re-serializes it without the fragment.

Note on similar-looking reports

Two things surface when searching this symptom and are not this bug:

  • Markdown-preview #fragment link failures — that is an Anthropic claude-code VS Code extension issue about relative file links, a different product and surface.
  • Forum reports about terminal links opening in the internal Browser Tab — those are about which browser opens, not about fragment loss.

I found no existing report of fragment stripping on the chat click path.

Operating System

MacOS

Version Information

Environment

  • Cursor 3.20.21
  • macOS (darwin 25.6.0)
  • Default browser: Google Chrome
  • No browser-related keys set in settings.json — no workbench.externalBrowser, no workbench.browser.openLocalhostLinks

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @jawads, thanks for the detailed report, and for ruling out the OS and Chrome up front.

In the Agents Window, a plain click on a GitHub pull request link goes through Cursor’s pull request handling first, which rebuilds the URL to the bare PR address before handing it to your browser, so the #comment anchor (and things like /files) get dropped. Right-click → Open in External Browser skips that step, which is why it keeps the anchor.

This should only affect pull request links for repos connected to Cursor, not fragment links in general. Could you confirm that with these steps?

  1. In the Agents Window chat, paste this link and left-click it: Example Domain
  2. Check Chrome’s address bar. The fragment should be kept here.
  3. Open Cursor Settings and find the Pull Requests section. Note what “PR Link Destination” is set to (Inside Cursor or Default Browser).
  4. Left-click a GitHub PR link with a #discussion_r… anchor for a repo that is NOT connected to your Cursor account, and check whether the anchor survives.

If step 1 keeps the fragment and only the GitHub PR links lose it, that matches what I found. In the meantime, right-click → Open in External Browser is the reliable way to land on the exact comment.

11

Hi @Colin thanks for quick response. Here are responses for your query:

1 & 2: fragment is preserved.
3: Default Browser.
4: NOT a repo connected to cursor: fragment is preserved. fragment is NOT preserved when PR is from a connected repo… ← issue identified