Canvases stored under per-launch temp project key — Publish fails with "Canvas file not found" (Windows, standalone/Glass app)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Canvases are persisted under a project key derived from a per-launch temporary path, so Publish fails with “Canvas file not found” and canvases become unreachable after a restart.

In the standalone app (Glass layout) on Windows, opening a multi-folder session produces an ad-hoc workspace whose identity is derived from a temp path that does not exist on disk. Canvases land here:

%USERPROFILE%\.cursor\projects\<project-key>\canvases\<name>.canvas.tsx

where <project-key> looks like C-Users-<SHORTNAME>-1-AppData-Local-Temp-<uuid>.

Two symptoms:

  1. A new uuid (new project key) is minted on every launch, even when the folder set is identical, so canvases created in one session are orphaned in the next. 30 temp-keyed project directories have accumulated on this machine, with canvas files stranded in the older ones.
  2. Publish reports “Canvas file not found” even though the .canvas.tsx file exists (23 KB) and its sibling status file reads {"status":"rendered"}.

The temp path that the key encodes does not exist — not even for the session currently running. Searching %LOCALAPPDATA%\Temp for the uuid of the live session returns no match, and the same is true for the previous session’s uuid. Canvases are therefore filed under an identity pointing at a phantom path.

Likely contributing cause: the same physical canvas file is registered twice under inconsistent path normalization, producing two different canvasIds. From the Cursor Agent Exec log:

15:44:30 Registered canvas {"path":"c:\\Users\\...\\canvases\\my-report.canvas.tsx","canvasId":"77bc00d4a9b1"}
15:52:15 Registered canvas {"path":"C:/Users/.../canvases/my-report.canvas.tsx","canvasId":"50f41e5972f5"}

Lowercase c: with backslashes versus uppercase C: with forward slashes. That duplicate identity looks like a plausible direct cause of the failed lookup, and appears fixable independently of the storage-location design.

The standalone app exposes no way to pin a stable project identity, so this is not user-correctable.

Steps to Reproduce

  1. On Windows, launch the standalone Cursor app (Glass layout, not the IDE layout).
  2. Open a multi-folder session (more than one root folder — mine is three: two local repos plus one OneDrive-backed folder).
  3. Have the agent create a canvas; confirm it renders.
  4. Attempt Publish on that canvas — it reports “Canvas file not found”.
  5. Fully exit Cursor, then relaunch from the taskbar or Start Menu.
  6. Observe a new ...AppData-Local-Temp-<uuid> project key under %USERPROFILE%\.cursor\projects\, with the canvas from step 3 unreachable.

To confirm the phantom path: take the uuid from the live session’s project key and search %LOCALAPPDATA%\Temp for it. There is no matching file or directory, even while that session is running.

Expected Behavior

  1. A canvas I create should stay reachable and publishable in later sessions, regardless of how the workspace was opened.
  2. Publish should resolve the canvas file that is on disk and rendered — and if it genuinely cannot find it, report the path it attempted rather than a bare “Canvas file not found”.
  3. Canvases should be stored durably — keyed to the folder set, or in a user-visible location — not under a per-launch temporary path.

Operating System

Windows 10/11

Version Information

  • Cursor 3.16.29 (also observed on 3.16.17)
  • Layout: Glass — standalone app, not the IDE layout
  • OS: Windows 11, build 26200
  • Workspace shape: multi-root, three folders (two local repos plus one OneDrive-backed folder)

Additional Information

Workarounds attempted — all failed

  • File → Open Workspace from File: does not exist in Glass. The File menu is New Agent, Open Folder (glass.openWorkspace, Ctrl+O), New Terminal, New Browser, Open IDE, Exit.
  • Save a real .code-workspace and open it: no UI path to open a workspace file in Glass.
  • Pass the .code-workspace as a launch argument (Cursor.exe "path\to\my.code-workspace", set on the taskbar shortcut): argument silently ignored. Relaunch still minted a fresh temp key; the stable key was never used.
  • Copy the canvas into a stable project key manually: not picked up; the running session reads only its own temp key.

The only workaround that preserves a stable key is opening a single folder, which forfeits the multi-root layout entirely.

Impact

  • Canvases cannot be shared, which is their main collaborative purpose. Publish is effectively unavailable to standalone multi-root users.
  • Work is silently lost: analysis rendered into a canvas becomes unreachable after a restart, with no warning that its storage was ephemeral.
  • Orphaned project directories accumulate with no cleanup (30 and counting on this machine).
  • No user remedy, since the app exposes no workspace-identity control.

Suggested fixes

  1. Derive the project key from the folder set rather than a temp workspace path — e.g. a hash of the sorted absolute root paths, so an identical folder set resolves to the same key every launch.
  2. Normalize paths before registering canvases: canonicalize drive-letter case and separators so one file cannot produce multiple canvasIds.
  3. Make Publish resolve the on-disk file, and report the path it attempted when it fails.
  4. Store canvases durably / user-visibly, or add an explicit save/export action so work is not tied to session identity.
  5. Optionally honor a .code-workspace launch argument in Glass (or add recent-workspaces), so a stable identity can be pinned.
  6. Garbage-collect orphaned temp-keyed project directories, or migrate their contents when a matching folder set reappears.

Related observation while filing this report

Agent-driven browser automation runs in a browser session that is not the visible Glass Browser panel, so a composer filled by the agent is invisible to the user; only the auto-saved Discourse draft revealed it. Separately, opening such a draft from the drafts list showed the form-template fields empty, so the saved content was not recoverable through the composer.

Diagnostics came from %USERPROFILE%\.cursor\projects\, %APPDATA%\Cursor\logs\, and %APPDATA%\Cursor\User\globalStorage\storage.json. Paths and canvas names above are genericized — happy to supply fuller log excerpts privately.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Follow-up — still reproduces on 3.18.9

Confirming this is still broken on Cursor 3.18.9, Windows 11 build 26200.

Today (2026-09-01) I opened a canvas that does exist on disk and is rendered:

%USERPROFILE%\.cursor\projects\c-spe-Orchestrator\canvases\dbos-payload-size.canvas.tsx (8.8 KB, last written 2026-09-01 12:37)

Publish → All Team Members can view still returns “Canvas file can not be found” in the lower-left.

On this machine there are 39 numeric / %LOCALAPPDATA%\Temp\<uuid> project keys under %USERPROFILE%\.cursor\projects\. 35 of them have a canvases\ directory; 0 of those contain a .canvas.tsx. Newest empty keys include 1788182688593 (2026-08-31) and C-Users-A0012784-AppData-Local-Temp-191b7171-716a-40b0-b712-5637ca5ffc91 (2026-08-27). Publish appears to look under one of those per-launch keys instead of the real workspace key (c-spe-Orchestrator).

No Cursor staff reply since the original post (2026-08-21). Topic is scheduled to auto-close ~2026-09-23.

7

Thanks for the report @Steve_Carlisle and @TSchutter for confirming it’s still on 3.18.9. Both are on our side, nothing you’re doing wrong:

  1. Multi-folder Glass sessions file canvases under a per-session identity rather than your folder set, so they orphan across restarts.
  2. On Windows, Publish compares the canvas path in two formats, so it reports “Canvas file not found” even though the file is there and rendered.

We’ve let the team know. No timeline yet, but I’ll post updates here. Workaround: a single-folder session keeps canvases reachable across restarts. Publish on Windows has no reliable user-side workaround right now, so that’s not on you.

8

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Publishing a shared canvas fails with the toast error Canvas file not found, even though the canvas file exists on disk, Preview renders correctly, and the canvas session is registered in Cursor logs.

This happens on Windows when a canvas is stored under the normal Cursor-managed path:

%USERPROFILE%\.cursor\projects\<project-slug>\canvases\*.canvas.tsx

Preview renders the full canvas content. Clicking Publish within a few seconds still fails with the same error.

Steps to Reproduce

  1. Open any workspace in Cursor 3.19.7 on Windows 11.
  2. Create or open a canvas via agent (stored under .cursor/projects/.../canvases/*.canvas.tsx).
  3. Open the canvas (file link, Open Canvas command, or canvas tab).
  4. Confirm Preview renders the canvas content.
  5. Click Publish in the canvas toolbar within a few seconds.

Actual: Toast shows Canvas file not found.

Also tried:

  • Publishing from the originating chat
  • Closing extra Canvas tabs first
  • Re-surfacing the canvas via agent write
  • Publishing immediately after open (within 2 seconds)

Log pattern (repeats every attempt):

  • Registered canvas with correct absolute path
  • Canvas session acquired
  • Canvas opened successfully with viewMode: glass (no beside-chat open logged)
  • Canvas destroyed within ~7–37 seconds
  • Publish fails even while Preview still shows cached render

Expected Behavior

Publish should upload the canvas and return a shareable link. The canvas file should resolve from the registered path while the session is active.

Operating System

Windows 10/11

Version Information

3.19.7 (Windows)

Additional Information

Related: Similar reports exist for canvas publish failures on Windows with Glass/standalone view mode.

Secondary symptom: Canvas card does not persist in chat UI after agent creates canvas — only a markdown file link remains. Logs show one Canvas surfaced event at creation.

Hypothesis (for Cursor team): Publish may require beside-chat canvas binding; all opens log viewMode: glass. Session may be destroyed before publish resolves the file path.

Does this stop you from using Cursor

No - Cursor works, but with this issue

11

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

Cursor version: Help → About Cursor. You’re on 3.19.13 (dd066f332fcea7382764400fde902f61920648d0, 2026-09-04).
OS: Windows 10 10.0.26100
Expected: Publish opens a team share dialog and copies a share URL.
Actual: Toast: Canvas file not found. Canvas still renders. Console is silent on click.

Summary
Every local .canvas.tsx under .cursor/projects//canvases/ fails to publish with “Canvas file not found.” The canvas compiles and renders. A 20-line smoke-test canvas fails the same way. Publish worked on this machine the previous day.

Steps to Reproduce

Steps

Open a rendered canvas (rolling gf-delivery-metrics.canvas.tsx, dated snapshot, or a new publish-smoke-test.canvas.tsx).
Wait until the dashboard paints (status file is {“status”:“rendered”}).
Click Publish.

Expected Behavior

Expected
Share dialog / team share URL.
Actual
Info toast: “Canvas file not found.” No network request, no DevTools console activity from the click.

Investigation notes

Share action passes plan/team/privacy gates (ShareCanvasAction then calls shareCanvas).
Failure is status: “canvas-missing” from getShareArtifact.
Canvas server keys registrations with sha256(“canvas:” + path).slice(0, 12). Lookup does not read the filesystem.
Same file hashes to different IDs depending on path spelling:
c:\Users... → 20dd7fd6425f
C:\Users... → aae65cb5e560
c:/Users/… → 57fa2fca5a79
Workbench shareCanvas normalizes with path.normalize(t.replace(/\/g,“/”)) before calling the provider. If register used a different spelling than share, the map miss is guaranteed.
Full process kill + relaunch, opening the canvas from the Canvases list, and a never-opened smoke test all still fail.
Canvas server on 127.0.0.1:61044 returns 403 to unauthenticated probes.

Operating System

Windows 10/11

Version Information

About Cursor. You’re on 3.19.13

For AI issues: which model did you use?

Auto Balance

Additional Information

I have been using this weekly so I’d love to have this fixed soon.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

14

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Where does the bug appear

Canvas (.canvas.tsx) - the Publish / share action in the canvas toolbar.

Summary

Publishing any canvas fails immediately with an error stating the canvas file
cannot be found. The canvas itself is fine: it is registered by the canvas
subsystem with a canvasId, it renders correctly, and its status sidecar
reports {"status":"rendered"}. No share link is produced and nothing appears
under Shared Canvases in the dashboard.

Publishing canvases worked previously on this same account and machine, so this
is a regression rather than a first-time setup problem.

Environment

  • Cursor version: TO FILL (Help > About > Copy)
  • OS: Windows TO FILL (version/build)
  • Account: company-managed team account. Privacy Mode is enabled in the
    storage-permitting mode (“Your code data will not be trained on or used to
    improve the product. Code may be stored to provide features such as
    Background Agent.”), admin-locked. Not Legacy Privacy Mode.
  • Also reproduced from a Remote SSH workspace (Windows client, Linux host,
    RHEL 8 / kernel 4.18.0) - see “Also tried” below.

Actual behavior

An error appears in the IDE immediately, reported as “Canvas file not found”
(TO FILL: paste the exact error text / attach screenshot). No link is
generated. The canvas never appears under Shared Canvases.

Evidence that the file is present and resolvable

Canvas log from the failing session (local Windows workspace):

19:17:01.232 [info] Canvas server started {"port":61847,"startDurationMs":2519}
19:17:01.581 [info] Registered canvas {"path":"C:\\Users\\<user>\\.cursor\\projects\\<project-key>\\canvases\\<name>.canvas.tsx","kind":"source","canvasId":"8cb4392ab74b"}
19:17:44.728 [info] Registered canvas {... same path, same canvasId ...}
19:17:51.011 [info] Registered canvas {... same path, same canvasId ...}
19:23:47.122 [info] Registered canvas {... same path, same canvasId ...}

Two observations:

  1. The canvas is registered with a stable canvasId and its full absolute
    path, immediately before the failing Publish click. The file demonstrably
    exists and is known to Cursor.
  2. There is no log entry for the Publish attempt at all - no upload, no
    HTTP request, no error. The action appears to be rejected before any work
    begins. Every registration is logged with "kind":"source"; no
    rendered-kind registration is ever logged, in case that is relevant to how
    Publish resolves the target.

Directory contents alongside the canvas (all present, provisioned by Cursor):

  • <name>.canvas.tsx (22 KB)
  • <name>.canvas.status.json containing {"status":"rendered"}
  • tsconfig.json
  • node_modules/ with cursor/canvas type declarations and @types/react

The canvas compiles with no TypeScript errors and imports only from
cursor/canvas.

Already ruled out

  • File missing on disk. The file is registered with a canvasId, renders,
    and has a rendered status sidecar.
  • Remote SSH path resolution. Initially suspected, since the canvas was
    first authored in a Remote SSH workspace where the file lives on the Linux
    host while the client is Windows. Reproduced identically in a purely local
    Windows workspace with no SSH involved, so this is not the cause.
  • Missing scaffolding. tsconfig.json and node_modules are present in
    the canvases directory.
  • Symlink / junction path mismatch. On the Linux host ~/.cursor is a
    symlink to another filesystem, which could plausibly cause a canonical-path
    mismatch. Ruled out: on Windows %USERPROFILE%\.cursor is a real directory
    (fsutil reparsepoint query reports it is not a reparse point), and the
    failure reproduces there with a literal non-linked path in the log.
  • Type errors / render failure. Canvas compiles clean and renders.
  • Legacy Privacy Mode. Account is on the storage-permitting Privacy Mode.
  • Plan / team membership. Publishing previously worked on this account, and
    the account has an active team context.
  • Canvas-specific issue. Multiple different canvases fail the same way,
    including one authored weeks earlier.

Also tried

  • Publishing from both a Remote SSH window and a purely local window - same
    result.
  • Opening the canvas via + > Canvas > Recent rather than the chat link.
  • Copying the canvas file to the client-side canvases directory while working
    in the Remote SSH window.

Questions

  1. Why is Publish rejected before any attempt is logged? Is there a
    server-side or policy check that fails silently at that point?
  2. Can the org-level Shared Canvases setting for this team be verified? If an
    admin disabled it, is “Canvas file not found” the expected error surface?
    That message would be misleading if so.
  3. Is this related to the reported issue where a publish attaches to whichever
    team was active at sign-in while the viewer checks a different team?

Impact

Blocks sharing canvases with teammates entirely. Workaround is to send the
.canvas.tsx file and have recipients place it in their own canvases
directory, which is manual and requires each recipient to run Cursor.

Steps to Reproduce

Steps to reproduce

  1. Open a local (non-SSH) workspace in Cursor on Windows.
  2. Have the agent create a canvas, or place a .canvas.tsx file directly in
    C:\Users\<user>\.cursor\projects\<project-key>\canvases\.
  3. Open the canvas; confirm it renders.
  4. Click Publish in the canvas toolbar.

Expected Behavior

Expected behavior

Cursor uploads a snapshot and returns a shareable link; the canvas appears
under Shared Canvases in the dashboard.

Operating System

Linux

Version Information

Version: 3.19.13 (system setup)
VS Code Extension API: 1.128.0
Commit: dd066f332fcea7382764400fde902f61920648d0
Date: 2026-09-04T17:41:16.065Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

17

https://forum.cursor.com/t/canvas-publish-fails-with-canvas-file-not-found-although-the-canvas-is-registered-and-renders/171005/4

Why was this post was closed and merged to this one? They do not describe the same issue.

My issue also happens when I run it from a local instance of Cursor.

@Colin

21

Hey @Matan_Malka!

I believe all reports in this thread cover the same “Canvas file not found” issue . Let me know if I’m missing something!

22

Update: resolved by rolling back to 3.17.8.

Downgrading from 3.19 to Cursor 3.17.8 fixed it. Publish now works immediately
— same machine, same account, same canvas file, no other changes. So this is a
client-side regression introduced somewhere between 3.17.8 and 3.19, not an
account, policy, or path problem.

On 3.19 the canvas was registered normally (Registered canvas ... canvasId ...
in the canvas log) and rendered fine, but clicking Publish produced a “canvas
file not found” error with no publish attempt logged at all — no upload, no
HTTP request, no failure entry. That silence is probably the useful clue: the
action was being rejected before it did any work, rather than failing during
resolution.

Everything environmental was ruled out beforehand and none of it was the cause:
file presence on disk, Remote SSH vs. purely local workspace, the tsconfig.json
and node_modules scaffolding in the canvases directory, TypeScript errors,
Legacy vs. storage-permitting Privacy Mode, plan and team membership, and
symlink/junction path mismatches on both the Linux and Windows sides.

Happy to supply full logs from 3.19 if that helps narrow down the regression.

23

I’d suggest not merging these. The original report is against 3.16, while the
recent ones — including mine — are against 3.19, and rolling back to 3.17.8
resolves it completely for me.

That’s the part I think rules out a single shared root cause: a build sitting
between the two reported versions is demonstrably unaffected. If it were one
continuous underlying bug, 3.17.8 would fail too. It looks more like two
separate regressions that happen to surface the same way to the user, and
merging them risks the 3.19 one being closed off the back of a fix (or a
diagnosis) that only applies to 3.16.

Happy to be corrected if there’s evidence linking them that I’m not seeing.

27

Hey @Matan_Malka, thanks for testing that!

You are right that the failure you hit began in 3.18. In the regular IDE layout, Publish on Windows worked through 3.17.x, and our usage data agrees with what you saw: 3.17.8 publishes fine in that layout, 3.19 does not.

The reason the reports are kept together is that the first reporter’s failure and yours come from the exact same lookup. When you click Publish, the app looks up the open canvas by the exact spelling of its file path. In 3.18, a change made the path the canvas is registered under differ from the one Publish uses, on every Windows machine.

Before 3.18, the same mismatch already happened in the Agents window when a canvas was opened from a file link, which is what the first reporter hit on 3.16.

28

Hello. I am facing the same issue since the last couple of versions. I am on the latest: 3.19.13 (system setup)

From Cursor:

Confirming the same Publish failure on Windows, and it is not a temp/per-launch project-key miss in this case.

Smoke test: agent wrote the canvas under this window’s own project key
…\.cursor\projects\<workspace-key>\canvases\publish-single.canvas.tsx
File is on disk, TypeScript-clean, opens beside chat. Publish still returns “Canvas file not found.”

That matches the 3.18+ lookup mismatch you described (registered path vs Publish path spelling), not the Agents-window temp-key case from 3.16.