Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
[Co-authored by Cursor AI]
When navigating from the References panel to certain files in a WSL2 workspace, Cursor throws:
CodeExpectedError: cannot open vscode-remote://wsl%2Bubuntu/<path>.tsx.
Detail: Files above 50MB cannot be synchronized with extensions.
at pmd.$tryOpenDocument
The files in question are 1–30 KB. The same files open fine when accessed directly from the file tree or Ctrl+P or (file find panel) ctrl-shift-f — only the references extension path fails. Failure is deterministic per-file (the same files always fail, others always succeed), and persists across Cursor restarts, OS restarts, full cache purges, and a fresh install.
If the actual file is loaded into workspace, then the references work. After the file is loaded once, it will continue to work thereafter, even if shut fown. But, if I restart cursor, the failure recurs.
Tried disabling anyshpere-remote-ssh; did not make a difference
The same workspace, opened in stock Microsoft VS Code with ms-vscode-remote.remote-wsl, exhibits no failure.
Steps to Reproduce
Reproduction (deterministic on my workspace)
(a)
- Open a WSL2-hosted folder in Cursor (
/home/<user>/dev/mustrd/poc). - Navigate to a file that imports a target component, e.g. an import of
CalendarStagesEditorScreenfromfrontend/src/components/screens/CalendarStagesEditorScreen.tsx. - Right-click the import → “Find All References” (or “Go to Definition”).
(b)
4. Click the reference in the References panel.
Expected Behavior
Expected: the file shows the references and would open when clicked
Actual: does not show the references below (only the filename) and when I click the filename get error toast “cannot open … Detail: Files above 50MB cannot be synchronized with extensions.” File is 1.5 KB on disk.
Workaround: open the file via the file tree or Ctrl+P first, then click the reference — works every time once the file is in a buffer.
Operating System
Windows 10/11
Version Information
Environment
Version: 3.1.17 (user setup)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
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
- WSL distro: Ubuntu (default, ext4 inside vhdx)
- Anysphere extensions installed:
anysphere.remote-ssh1.0.48 (2026-04-10)anysphere.remote-wsl1.0.13 (2026-03-29)
- Other relevant extensions: Auto Rename Tag, ES7+ React snippets, Highlight Matching Tag (none of these are file-system providers)
- No Microsoft remote extensions installed (no
ms-vscode-remote.*) - AV: McAfee (default install on a new machine) — verified not the cause via VS Code cross-check on the same machine
Additional Information
Console error (Help → Toggle Developer Tools → Console)
[Extension Host] rejected promise not handled within 1 second:
CodeExpectedError: cannot open vscode-remote://wsl%2Bubuntu/home/rohan/dev/mustrd/poc/frontend/src/components/screens/CalendarStagesEditorScreen.tsx.
Detail: Files above 50MB cannot be synchronized with extensions.
at pmd.$tryOpenDocument (vscode-file://vscode-app/c:/Users/rohan/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:38268:11118)
File on disk (WSL side)
$ stat frontend/src/components/screens/CalendarStagesEditorScreen.tsx
Size: 1581 Blocks: 8 IO Block: 4096 regular file
$ file frontend/src/components/screens/CalendarStagesEditorScreen.tsx
JavaScript source, Unicode text, UTF-8 text
$ lsattr frontend/src/components/screens/CalendarStagesEditorScreen.tsx
--------------e------- (no special attributes)
Plain UTF-8, ext4, no xattrs, no symlinks, single hardlink, owned by the workspace user. Identical to other files in the same directory that open without error.
Other startup errors that may or may not be related
ERR Unable to create workbench contribution 'remoteTerminalBackend'.
Error: A terminal backend with remote authority 'wsl+ubuntu' was already registered.
at VCv.registerTerminalBackend ...
at new nkl ...
ERR Extension 'anysphere.remote-ssh' appears in product.json but enables LESS API proposals than the extension wants.
package.json (LOSES): resolvers, tunnels, contribViewsRemote, terminalDataWriteEvent, cursorTracing, cursorNoDeps
product.json (WINS): resolvers, tunnels, terminalDataWriteEvent, contribRemoteHelp, contribViewsRemote, telemetry, cursorTracing
ERR [LocalProcess1][resolveAuthority(wsl,1)][1850ms] returned an error Object
The duplicate wsl+ubuntu backend registration suggests anysphere.remote-ssh and anysphere.remote-wsl both register a handler for the same authority. Disabling anysphere.remote-ssh (leaving WSL only) silences the duplicate-backend error but does not fix the 50 MB issue — so the duplicate registration may be a separate bug.
Things ruled out
| Hypothesis | Verdict | How verified |
|---|---|---|
| File actually >50 MB |  |
stat shows 1.5 KB |
| File is binary / wrong encoding / has BOM | |
file says UTF-8 plain |
| Symlink / hardlink oddity | |
lsattr, stat -c '%h' clean |
| Stale Cursor workspace storage | |
Deleted %APPDATA%\Cursor\User\workspaceStorage\<hash>, reproduced after rebuild |
Stale ~/.cursor-server cache on WSL |
|
Deleted ~/.cursor-server/data/User/workspaceStorage, logs, CachedProfilesData, reproduced after rebuild |
| Stale WSL distro state | |
Full wsl --shutdown and OS reboot, reproduced |
| Cursor version | |
Updated to latest, reproduced |
| Conflicting Microsoft remote extensions | |
None installed |
| Tracked vs untracked file (git) | |
git add -N on a failing file did not fix it |
Antivirus interference (McAfee on \\wsl.localhost\) |
|
Plain VS Code with ms-vscode-remote.remote-wsl on the same workspace, same machine, McAfee unchanged does not reproduce |
| Duplicate WSL backend registration | Likely unrelated | Disabling anysphere.remote-ssh silences the duplicate-registration warning but the 50 MB issue persists |
The VS Code cross-check is the strongest evidence that the bug is inside anysphere.remote-wsl (or how Cursor packages it), not below the IDE layer.
Hypothesis
anysphere.remote-wsl’s file-system provider returns an incorrect FileStat.size on stat for certain files (likely a stale or bogus value that exceeds the 20 MB tokenization / 50 MB extension-sync internal limits). When VS Code’s extension host calls workspace.openTextDocument(uri) from an extension (e.g. the references view), the size check rejects the open before content is ever read. Direct file-tree opens go through a different code path that doesn’t hit this check, which is why the workaround works.
Suggested investigation
- Add logging in
anysphere.remote-wsl’sFileSystemProvider.statfor the failing URIs and capture the returnedFileStat. - Compare with the value
ms-vscode-remote.remote-wslreturns for the same path on the same machine. - Check for any per-file caching keyed on inode or path that could be returning stale entries from a prior session.
Does this stop you from using Cursor
No - Cursor works, but with this issue