Canvas could not load over Remote-SSH (Windows client → Linux): client sends POSIX path with backslashes, remote validator rejects it as path-not-managed-canvas

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Where does the bug appear (feature/product)?

Cursor IDE — Canvas (rendered .canvas.tsx) over Remote-SSH

Describe the Bug

On a Windows Cursor client connected to a Linux host via Remote-SSH, opening any canvas shows “Canvas could not load”.

The canvas file is valid (TypeScript check: no errors) and lives in the managed directory:

~/.cursor/projects/<workspace>/canvases/<name>.canvas.tsx

The Linux remote extension host never starts the canvas server. Every registration attempt is rejected:

Rejected canvas registration for invalid path {“kind”:“source”,“reason”:“path-not-managed-canvas”}

Root cause: the Windows client rewrites the remote POSIX path with Windows backslashes before sending it to the Linux extension host, e.g.

\home.cursor\projects\canvases.canvas.tsx

Steps to Reproduce

  1. On Windows, open Cursor and Remote-SSH into a Linux machine.
  2. Have the agent create a .canvas.tsx under ~/.cursor/projects/<workspace>/canvases/.
  3. Open the canvas (chat link, Canvas view, or the .canvas.tsx file).
  4. Observe “Canvas could not load”.
  5. On the remote host, check ~/.cursor-server/data/logs/<session>/exthost*/anysphere.cursor-agent-exec/*.log for path-not-managed-canvas.

Expected Behavior

The Linux host should receive a POSIX path (/home/.../foo.canvas.tsx) and register the canvas. The canvas server should start (Canvas server started / Registered canvas) and the panel should render.

Operating System

Linux

Version Information

  • Cursor 3.19.13 (stable)
  • Remote server commit: dd066f332fcea7382764400fde902f61920648d0

Additional Information

Suggested fix

Either (or both):

  1. Client: do not convert a remote POSIX path to Windows \ when talking to a Linux extension host. Keep / for remote paths.
  2. Remote validator: before path.isAbsolute(), normalize \ → / for paths that are not Windows drive-letter paths (^[A-Za-z]:[\\/]). Then run the existing checks unchanged (managed-canvas regex, regular file, not a symlink, re-validate realpath).
    Drive-letter local-Windows paths should stay untouched. Directory-escape attempts and non-.canvas.tsx files should still be rejected (we verified that after separator normalization).

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @huatian-li, thanks for the detailed report. Your path analysis matches what we see on our side.

This is a known issue we are already tracking: when a Windows client is connected to a Linux host over Remote-SSH, the Agents window hands the canvas path to the remote host in Windows form and the host rejects it. I have added your report to it.

Two things that should work in the meantime:

  1. In the Agents window, close any canvas tab that is showing “Canvas could not load”, then open the canvas again from the + button, then Canvas, then Recent. Opening from that list sends the path in the right form.

  2. Or open the .canvas.tsx file in the regular Cursor editor window (the classic IDE view). Canvas rendering there is not affected by this.

Could you let me know whether either of those renders the canvas for you? That helps us confirm the fix covers every path.