Canvas: single click on <Link> opens the same external URL multiple times

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In Canvas preview, a <Link> from cursor/canvas triggers multiple opens of the same external URL from one user click (multiple identical browser tabs and/or repeated “open external website” confirmations).

Minimal repro:

import { Link } from "cursor/canvas";

export default function Repro() {
  return <Link href="https://hostsailor.com/">test</Link>;
}

### Steps to Reproduce
1. Create or open a `.canvas.tsx` file and open Canvas preview.
2. Render: `import { Link } from "cursor/canvas";` and `<Link href="https://hostsailor.com/">test</Link>`.
3. Click the link exactly once in the preview.
4. If Cursor asks to allow opening an external site, confirm once.

Actual: several identical tabs/windows open for the same URL, and/or the confirmation dialog appears multiple times.
Expected: one tab and one confirmation per click.

### Expected Behavior
One click on `<Link>` in Canvas preview should open the target URL once (single browser tab / single external open).



### Operating System
Windows 10/11

### Version Information
Version: 3.2.11 (system setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

### For AI issues: which model did you use?
N/A — not an AI/chat issue; Canvas preview / Link navigation.

### For AI issues: add Request ID with privacy disabled
N/A — Canvas `<Link>` opens external URL multiple times; no chat request involved.

### Additional Information
Workaround: avoid `<Link>` in Canvas and show plain URLs as text; then the problem does not occur.

Also observed when `<Link>` was used inside `<Table>` cells; issue may be related to duplicate click/navigation handling in the Canvas webview.

### Does this stop you from using Cursor
No - Cursor works, but with this issue
4

believe this is the same as the bug I reported, please bump! Canvas SDK: <Link> click handlers leak across webview mounts — clicking a link opens N tabs after N canvas opens

8

Hey, thanks for the detailed report with steps to repro. This is the same bug as in the thread @kbrouder linked to: Canvas SDK: <Link> click handlers leak across webview mounts — clicking a link opens N tabs after N canvas opens. It’s listener accumulation in the Canvas webview, so the number of tabs opened grows with the number of Canvas tab open and close cycles.

I’ve filed it internally and linked both threads. No ETA yet, but your workaround (using a plain URL as text instead of <Link>) works, and I’d stick with that for now. I’ll reply here once there’s an update on the fix.

9

Describe the Bug

when I click link at Canvas, it opens 8 tabs in my browser

Steps to Reproduce

  1. Just click the link

image
image1300×496 32.4 KB

Expected Behavior

  1. Only one tab is opened

Operating System

MacOS

Version Information

Version: 3.6.33
VS Code Extension API: 1.105.1
Commit: 453f0b5a181a2308f4194369774059e533143529
Date: 2026-06-01T01:38:32.281Z
Layout: editor
Build Type: Nightly
Release Track: Nightly
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

11

Hi @deanrie ,

Seeing the same bug with the inbuilt browser: Simple Browser: window.open host-side fanout leaks across tab close cycles — one click opens N tabs after N close-all cycles

15

Hey @Kirevg,

I’m back with the update I promised. The duplicate opens from a single click on a Canvas <Link> where tabs kept piling up after closing and reopening the canvas, plus the repeated “open external website” confirmation prompts, were fixed in a recent Cursor update.

You were on 3.2.11, which is pretty far behind the current stable. Please update to the latest version, the issue should be gone, and the workaround of using a plain URL instead of <Link> isn’t needed anymore. Let me know if you can still reproduce it.

cc @kbrouder @Eugen_Konkov @Mark_Commins