Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
CURSOR BUG REPORT
TITLE
Canvas cannot load on local Windows: cursor-agent-exec rejects a valid managed Canvas source as path-not-managed-canvas; clean restart can also hit Canvas provider timeout before agent-exec activation completes
SYNOPTIC OVERVIEW
Rendered Cursor Canvas does not load in a normal local Windows workspace.
Two distinct failure modes were reproduced:
FAILURE MODE A - MANAGED PATH REJECTION
FAILURE MODE B - CANVAS PROVIDER TIMEOUT
DATE INVESTIGATED
September 30, 2026
Steps to Reproduce
Two distinct failure modes were reproduced:
FAILURE MODE A - MANAGED PATH REJECTION
Developer Tools initially reported:
[agent_exec] Rejected canvas registration for invalid path
kind: “source”
reason: “path-not-managed-canvas”
A diagnostic-only logging modification was temporarily added to Cursor’s shipped cursor-agent-exec dist/main.js. No validation behavior was modified. The instrumentation added only path:e.path to the existing warning object.
The resulting runtime object was:
arch: “x64”
channel: “stable”
client_version: “3.22.12”
kind: “source”
layout: “unifiedAgent”
path: “c:/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases/Canvas-Storage-Test.canvas.tsx”
platform: “win32”
reason: “path-not-managed-canvas”
This was immediately followed by:
[canvas] Canvas session acquire failed: exception
The exact runtime path rejected by cursor-agent-exec therefore is:
c:/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases/Canvas-Storage-Test.canvas.tsx
FAILURE MODE B - CANVAS PROVIDER TIMEOUT
After a subsequent clean Cursor restart, Canvas did not reach source registration at all.
Developer Tools reported:
[canvas] Canvas session acquire failed: provider timeout
arch: “x64”
channel: “stable”
client_version: “3.22.12”
layout: “unifiedAgent”
platform: “win32”
waitedMs: 10058
In this attempt, there was no Rejected canvas registration message because Canvas failed before a CanvasServerProvider became available.
USER-VISIBLE BEHAVIOR
Typical sequence:
Loading Canvas
|
v
wait
|
v
Canvas couldn’t load
The rendered Canvas is unavailable.
Opening the .canvas.tsx source with File → Open File or File → Recent displays ordinary TSX source text rather than a rendered Canvas.
REPRODUCTION
- Start Cursor 3.22.12 Stable on local Windows.
- Open:
G:\MexAtlantic-MT5\MexAtlantic-MT5.code-workspace - Create/open a native Cursor Canvas.
- Attempt rendered Canvas view.
- Observe “Loading Canvas” followed by “Canvas couldn’t load”.
- Open Help → Toggle Developer Tools → Console.
- Depending on runtime state, observe either:
a. Rejected canvas registration / path-not-managed-canvas, or
b. Canvas session acquire failed: provider timeout.
MANAGED CANVAS SOURCE VALIDATION
The managed Canvas test file exists at:
C:\Users\ericr.cursor\projects\g-MexAtlantic-MT5\canvases\Canvas-Storage-Test.canvas.tsx
File properties:
Length: 494 bytes
CreationTime: 2026-09-30 14:38:56
LastWriteTime: 2026-09-30 14:38:56
Attributes: Archive
LinkType: none
Target: none
Resolved path:
C:\Users\ericr.cursor\projects\g-MexAtlantic-MT5\canvases\Canvas-Storage-Test.canvas.tsx
Parent Canvas directory:
C:\Users\ericr.cursor\projects\g-MexAtlantic-MT5\canvases
Attributes: Directory
LinkType: none
Target: none
Cursor project-state directory:
C:\Users\ericr.cursor\projects\g-MexAtlantic-MT5
Attributes: Directory
LinkType: none
Target: none
Real workspace:
G:\MexAtlantic-MT5
Attributes: Directory
LinkType: none
Target: none
Therefore:
Canvas file symlink: NO
Canvas directory junction: NO
Project-state junction: NO
Workspace junction: NO
CURSOR 3.22.12 MANAGED-CANVAS VALIDATOR
Inspection of:
C:\Users\ericr\AppData\Local\Programs\cursor\resources\app\extensions\cursor-agent-exec\dist\main.js
found the managed-Canvas regex:
/(?:^|[\/]).cursor[\/]projects[\/][^\/]+[\/]canvases[\/][^\/]+.canvas.tsx$/i
Conceptually, the source validator performs:
function isAbsoluteCanvasPath(path) {
return pathModule.isAbsolute(path) ||
/[1]:[\/]/.test(path);
}
function isManagedCanvasPath(path) {
return managedCanvasRegex.test(path);
}
async function validateCanvasSource(path) {
if (!isAbsoluteCanvasPath(path) || !isManagedCanvasPath(path)) {
return {
status: “invalid”,
reason: “path-not-managed-canvas”
};
}
const file = await inspectFileAndRealPath(path);
if ("status" in file) {
return file;
}
if (
isAbsoluteCanvasPath(file.realPath) &&
isManagedCanvasPath(file.realPath)
) {
return {
status: "valid",
stats: file.stats,
realPath: file.realPath
};
}
return {
status: "invalid",
reason: "realpath-not-managed-canvas"
};
}
The file-inspection code also rejects a source if the object is not a regular file or is a symbolic link.
INDEPENDENT TEST OF EXACT REJECTED RUNTIME PATH
The exact path captured from the live Cursor runtime was tested independently:
c:/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases/Canvas-Storage-Test.canvas.tsx
Results:
Absolute path test: True
Managed Canvas test: True
Physical file exists: True
RESULT: ALL THREE TESTS PASSED
Therefore the visible runtime path:
- qualifies as a Windows absolute path,
- matches Cursor’s managed Canvas path structure, and
- identifies an existing physical source file.
IMPORTANT: FINAL ERROR MAY MASK INNER VALIDATION FAILURE
Further inspection of cursor-agent-exec shows the source registration path conceptually performs:
const primary = await validateCanvasSource(e.path);
return primary.status === “valid”
? primary
: validateAsCloudCanvasSource(…);
The cloud/cache fallback can itself return:
reason: “path-not-managed-canvas”
Therefore the final logged path-not-managed-canvas reason may hide the original cause returned by the primary source validator.
Possible primary/inner failures include:
stat-ENOENT
stat-EACCES
stat-failed
path-not-regular-file
realpath-not-managed-canvas
path-not-managed-canvas
This masking behavior should be reviewed because it makes the final diagnostic potentially misleading.
WORKBENCH → AGENT-EXEC FLOW
Inspection of:
C:\Users\ericr\AppData\Local\Programs\cursor\resources\app\out\vs\workbench\workbench.desktop.main.js
found the rendered Canvas component conceptually equivalent to:
function CanvasView({
canvasPath,
canvasPreviewKind,
canvasService,
…
}) {
…
const session = await canvasService.acquireSession(
canvasPath,
{ kind: canvasPreviewKind }
);
}
The downstream call flow is:
Xhy.canvasPath
|
v
acquireSession(canvasPath)
|
v
registerCanvasSession({
kind: kind,
path: canvasPath
})
|
v
canvasServerProvider.registerCanvas(…)
|
v
cursor-agent-exec
|
v
ua(e.path)
The acquireSession caller was found exactly once in the workbench bundle.
SUSPICIOUS PATH-RESOLUTION ASYMMETRY
Cursor contains resolveManagedCanvasPath().
openCanvasPath() explicitly resolves/validates the path first:
input
|
v
resolveManagedCanvasPath()
|
v
validated managed path
|
v
Canvas Editor
getInlinePreviewUrl() also resolves the source before registering it:
input
|
v
resolveManagedCanvasPath()
|
v
validated managed path
|
v
registerCanvas()
But the rendered Canvas session path is:
canvasPath
|
v
acquireSession()
|
v
registerCanvasSession()
|
v
registerCanvas()
|
v
agent-exec validator
There is no explicit resolveManagedCanvasPath() call inside acquireSession().
This inconsistency deserves direct engineering review. A common defensive normalization/validation boundary may eliminate an entire class of Canvas path-handoff failures.
PREVIEW.PATH INVESTIGATION
The rendered component uses logic conceptually equivalent to:
const sourcePath = descriptor?.path ?? outerPath;
CanvasView({
canvasPath:
isReadOnlyPreview
? descriptor?.preview.path
: descriptor?.preview.path ?? sourcePath,
canvasPreviewKind:
descriptor?.preview.kind
});
Searches for preview.path producers showed the explicit preview objects in the Canvas service region primarily correspond to cloud Canvas bundles, e.g.:
preview: {
kind: “bundle”,
path: bundlePath,
…
}
The observed failing registration explicitly had:
kind: “source”
so the captured source failure is not simply the cloud bundle branch.
PROVIDER TIMEOUT / STARTUP-RACE EVIDENCE
Fresh-start extension activation timing:
anysphere.cursor-agent-exec
Total: 14,711 ms
Code loading: 2,468 ms
Activate call: 358 ms
Activate resolved: 11,885 ms
vscode.npm
Total: 25,661 ms
ms-vscode.powershell
Total: 34,058 ms
Earlier startup:
cursor-agent-exec: 17,789 ms
vscode.npm: 20,588 ms
PowerShell: 30,399 ms
The Canvas provider timeout was:
waitedMs: 10058
This creates a strong timing mismatch:
Canvas gives up: ~10.1 sec
cursor-agent-exec activates: ~14.7-17.8 sec
Likely startup-race flow:
Cursor starts
|
±--------------- Canvas waits ----------------+
| |
0s 10.1s
| |
| Canvas gives up
|
±------ cursor-agent-exec still activating --------+
|
14.7-17.8s
|
provider ready?
A Canvas request can therefore fail before the extension responsible for registering the Canvas server provider finishes activation.
EXTENSION-HOST INSTABILITY
Additional Developer Tools evidence:
[composer] Extension host became UNRESPONSIVE
[SearchService] Extension activation timed out after 5000ms
[PluginsProviderService] getPluginMcpServers timed out after 30011.1ms
A separate extension-host exception was observed:
TypeError: Cannot read properties of null (reading ‘elapsed’)
at K0e.getStats
at extensionHostProcess.js
Agent-exec also reported:
[Extension Host:agent-exec]
computeGlobalCache: slow
totalMs: 4770
cloudRule: 28
codebaseRef: 113
subagents: 2031
cursorRules: 4769
ruleCount: 113
This supports a broader Cursor extension-host latency/stability problem and may directly contribute to the Canvas provider startup timeout.
PSES / POWERSHELL INVESTIGATION
PowerShell Editor Services repeatedly initializes successfully.
Fresh startup:
PowerShell Extension: 2025.4.0
PowerShell: 7.6.6
PSES process count: 1
PSES named pipes: 2
Example startup:
16:38:56.755 Starting ‘PowerShell 7.6 (x64)’
16:38:57.179 PowerShell process started PID 18592
16:39:06.228 Started PowerShell v7.6.6
PSES therefore works while Canvas fails.
A previous PSES instance later terminated after approximately one hour:
15:46:50.970 Language service connection closed
15:46:50.984 Connection to PowerShell Editor Services was closed
15:46:52.593 PowerShell PID 11720 terminated
No corresponding Windows Application crash or PowerShell Operational crash event was found.
This may be a separate symptom of broader extension-host instability, but PSES is not the root cause of the reproducible Canvas failures.
ELECTRON / CHROMIUM STORAGE INVESTIGATION
An earlier Cursor invocation emitted:
service_worker_storage.cc:1814
Failed to delete the database: Database IO error
This prompted offline storage testing.
With every Cursor.exe process stopped:
Cursor processes: 0
Service Worker exclusive failures: 0
Local Storage exclusive failures: 0
Session Storage exclusive failures: 0
LevelDB error-text hits: 0
LOCK files present: 8
Every Service Worker database file passed exclusive-access testing:
000003.log PASS
CURRENT PASS
LOCK PASS
LOG PASS
LOG.old PASS
MANIFEST-000001 PASS
Other environment results:
NTFS permissions: Full Control
System drive free: approximately 106 GB
Database read failures: 0
Persistent Chromium/Electron storage corruption is therefore not supported by the evidence.
The earlier Database IO error remains an independent runtime concern but does not explain the direct Canvas provider/path failures documented here.
WORKSPACE / PROJECT-ID INVESTIGATION
Cursor project-state directories included:
g-MexAtlantic-MT5
g-MexAtlantic-MT5-MexAtlantic-MT5
g-MexAtlantic-MT5-MexAtlantic-MT5-code-workspace
g-MexAtlantic-MT5-MQL5
c-Users-ericr-cursor-projects-g-MexAtlantic-MT5-canvases
Timestamp analysis identified the currently active identity as:
g-MexAtlantic-MT5
because it received current terminal activity during the running Cursor session.
The other entries appear historical or troubleshooting-related. Their existence alone does not establish corruption.
The g- component itself is not invalid. Cursor’s source validator permits any single project-identity directory underneath .cursor/projects.
WORKSPACE STORAGE HISTORY
Relevant workspaceStorage identities included:
50c9f1107312c0b12c2d4d9565dcdd3b
file:///g%3A/MexAtlantic-MT5/MexAtlantic-MT5.code-workspace
6877c039c3e4b4d5ce1b1e4ec8a675bf
file:///c%3A/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases
a1f3b429e047fcf0859c480d07577be8
file:///c%3A/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases
e2e2cd3d685157cc6aa66e4b58349b64
file:///g%3A/MexAtlantic-MT5
The two historical contexts treating the managed Canvas directory itself as a folder/workspace were likely created during prior Canvas troubleshooting and should not automatically be treated as the original cause.
CURRENT WORKSPACE SQLITE STATE
The active workspace database was inspected read-only while honoring its WAL state.
No current serialized workbench.input.canvas / malformed canvasPath record was found.
history.entries does contain the correct managed Canvas URI:
file:///c%3A/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases/Canvas-Storage-Test.canvas.tsx
It is stored there as a normal file entry:
{
“resource”: “file:///c%3A/Users/ericr/.cursor/projects/g-MexAtlantic-MT5/canvases/Canvas-Storage-Test.canvas.tsx”,
“forceFile”: true,
“options”: {
“override”: “default”
}
}
This explains why File → Recent opens text source rather than rendered Canvas.
Older Canvas file/editor history also references:
xauusd-capital-strategy.canvas.tsx
xauusd-path-probe.canvas.tsx
ut100-v14r6-sweep-diagnostic.canvas.tsx
Those entries are historical editor state and do not establish the cause of the current rendered-Canvas failure.
MOST PROBABLE ROOT CAUSES
ROOT CAUSE 1 - CANVAS PROVIDER STARTUP TIMEOUT / RACE
Confidence: HIGH
Evidence:
- Canvas waits approximately 10.1 seconds.
- cursor-agent-exec repeatedly takes approximately 14.7-17.8 seconds to activate.
- Extension host repeatedly becomes unresponsive.
- SearchService and PluginsProviderService time out.
Likely behavior:
Canvas requests provider
|
v
cursor-agent-exec still activating
|
v
10-second Canvas timeout expires
|
v
Canvas fails
|
v
agent-exec/provider may become ready later
Suggested engineering fixes:
- Register the Canvas server provider earlier in cursor-agent-exec activation.
- Decouple provider registration from slow global-cache/rules/subagent initialization.
- Increase or remove the rigid provider wait timeout.
- Retry while extension activation is known to remain in progress.
- Do not present a final Canvas failure while provider activation is still outstanding.
ROOT CAUSE 2 - PRIMARY SOURCE VALIDATION ERROR MASKED BY CLOUD FALLBACK
Confidence: HIGH
Evidence:
- Exact runtime path is valid by the visible primary tests.
- Final reason remains path-not-managed-canvas.
- Source registration code invokes a secondary cloud/cache validation when primary source validation fails.
- That fallback can replace the primary failure reason with the generic path-not-managed-canvas.
Suggested engineering fix:
Preserve both primary and fallback errors, e.g.:
{
status: “invalid”,
primaryReason: primary.reason,
fallbackReason: fallback.reason,
path: path
}
Diagnostic logs should include path, primaryReason, fallbackReason, realPath, isFile, and isSymbolicLink.
ROOT CAUSE 3 - INCONSISTENT PATH RESOLUTION AT RENDERED-SESSION BOUNDARY
Confidence: MEDIUM-HIGH
Evidence:
- openCanvasPath() calls resolveManagedCanvasPath().
- getInlinePreviewUrl() calls resolveManagedCanvasPath().
- rendered acquireSession() passes its canvasPath directly to registerCanvasSession().
Suggested engineering fix:
Normalize/validate every source path at one common boundary before source registration, rather than relying on every upstream caller to supply a fully normalized path.
ROOT CAUSE 4 - BROADER EXTENSION-HOST INSTABILITY
Confidence: MEDIUM
Evidence:
- Extension host UNRESPONSIVE events.
- SearchService activation timeout.
- PluginsProviderService timeout.
- K0e.getStats null/elapsed TypeError.
- PowerShell, npm, and agent-exec all show unusually long activations.
- Agent-exec global-cache computation is slow.
This likely contributes to Root Cause 1 and may also explain unrelated extension/PSES instability.
WHAT HAS BEEN RULED OUT / NOT SUPPORTED
PowerShell 7.6.6 NOT indicated
PSES configuration NOT indicated
PSES startup works
NTFS permissions normal
Insufficient disk space no
Canvas file missing no
Canvas source symlink no
Canvas directory junction no
Workspace junction no
Persistent LevelDB lock no
Persistent Electron corruption not demonstrated
Incorrect g- project prefix no
Invalid React/TSX source failure occurs earlier
Simple malformed runtime path independent tests all pass
Stale serialized Canvas editor not found in active workspace DB
RELATED KNOWN ISSUE
Cursor Community has an existing confirmed path-not-managed-canvas issue involving a Windows client connected to Linux via Remote-SSH. In that case, Cursor staff confirmed that an upstream component handed the Canvas path to the validator in the wrong representation.
The present report is NOT Remote-SSH. This is a local Windows workspace. However, both cases fail at the same managed-Canvas validation boundary and demonstrate that upstream path handoff/normalization is security-sensitive and can produce path-not-managed-canvas even when the underlying Canvas is legitimate.
A separate Cursor Community Canvas report also shows Cursor support specifically requesting Developer Tools Console errors and cursor-agent-exec / Canvas extension-host evidence when Canvas fails to render.
REQUESTED DEVELOPER ACTIONS
-
Investigate why Canvas provider acquisition times out after approximately 10 seconds while cursor-agent-exec activation repeatedly takes approximately 15-18 seconds.
-
Register CanvasServerProvider before expensive cursor-agent-exec initialization, especially global cache/rules/subagent work.
-
Preserve the original source-validator reason instead of overwriting it with the cloud-cache fallback reason.
-
Add diagnostic fields:
- path
- primaryReason
- fallbackReason
- realPath
- isFile
- isSymbolicLink
-
Review rendered Canvas acquireSession() for the missing/implicit resolveManagedCanvasPath() step used elsewhere.
-
Investigate the extension-host exception:
TypeError: Cannot read properties of null (reading ‘elapsed’)
at K0e.getStats
extensionHostProcess.js
-
Investigate repeated extension-host UNRESPONSIVE events and long activation times.
-
Add a supported retry/recovery path when Canvas provider activation finishes after the UI timeout.
FAILURE FLOW DIAGRAM
CURSOR 3.22.12
|
v
Rendered Canvas request
|
+-------------+-------------+
| |
Provider available? Provider missing
| |
YES |
| v
| wait ~10.1 sec
v |
registerCanvas(source) X
| PROVIDER TIMEOUT
v |
ua(e.path) v
| Canvas couldn't load
v
primary validation
|
failure?
|
v
cloud/cache fallback
|
v
path-not-managed-canvas
|
v
registration rejected
|
v
Canvas couldn't load
PATH PIPELINE DIAGRAM
OPEN CANVAS PATH
input
|
v
resolveManagedCanvasPath()
|
v
validated managed path
|
v
Canvas editor
INLINE PREVIEW
input
|
v
resolveManagedCanvasPath()
|
v
validated managed path
|
v
registerCanvas()
RENDERED SESSION
canvasPath
|
v
acquireSession()
|
v
registerCanvasSession()
|
v
registerCanvas()
|
v
cursor-agent-exec validator
OVERALL ASSESSMENT
The collected evidence strongly supports a Cursor 3.22.12 Canvas / extension-host product defect rather than a local configuration problem.
At least two reproducible product-level failure modes exist:
-
A Canvas-provider startup race in which the approximately 10-second Canvas provider timeout expires before cursor-agent-exec finishes its observed approximately 15-18-second activation.
-
A source-registration/diagnostic problem in which a valid, existing managed Canvas source ultimately generates path-not-managed-canvas, potentially because the primary validator’s actual failure reason is lost when the cloud/cache fallback fails.
A broader extension-host performance/stability problem is a plausible contributing factor.
SEVERITY
High for Canvas functionality.
Rendered Canvas is effectively unusable. Other IDE functionality remains available, but there are independent symptoms of extension-host instability.
DIAGNOSTIC INSTRUMENTATION / RESTORATION NOTE
During diagnosis, two temporary logging-only modifications were applied to:
C:\Users\ericr\AppData\Local\Programs\cursor\resources\app\extensions\cursor-agent-exec\dist\main.js
No validator/security logic was bypassed or weakened.
Pristine original SHA256:
2A0E07B7E9479B856072F5FCC8A1E5B88E2218C8F5071D445F47938F44D62D64
After first logging instrumentation:
46A0AE17C04D3397B3CB280BFBBD28D2B1CFB00040BB2AE00E798AF4238AF917
After second logging instrumentation:
E941726E500753C8CE6209B091456B07CEA3F35E4C00CC3D4BD8272AB34C0BC9
The logging-only changes should be rolled back in reverse order after this diagnostic capture, and the final SHA256 should again equal the pristine original hash.
END OF REPORT
Operating System
Windows 10/11
Version Information
PRODUCT / ENVIRONMENT
Cursor IDE
Cursor version: 3.22.12 Stable
VS Code compatibility/API: 1.128.0
Electron: 42.10.0
Platform: Windows x64
Layout: unifiedAgent
PowerShell: 7.6.6
PowerShell extension: 2025.4.0
For AI issues: which model did you use?
Not Relevant - Cursor IDE integration issue with Canvas
Additional Information
See attached text bug report
Does this stop you from using Cursor
No - Cursor works, but with this issue
A-Za-z ↩︎