Some IDE constraints break the NPM tasks/scripts extension

seaders · July 3, 2026, 10:21am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

We have a project built on k8s/linkerd which is developed locally with tilt, and then deployed to aws through their cdk tools.

Many of these already have helper scripts in their package.json, and many libraries we use are in typescript already, so we use the NPM Scripts window to run tasks from there. When this workflow works, it’s perfect, but sometimes there’s an error that brings it down completely.

Sometimes, on startup, no tasks are discovered, no package.json files are shown and instead, this error,

Error: Npm task detection: failed to parse the file /Users/Shared/Developer/workspaces/tilt/lmr/package.json

This is a red-herring and comes from here, where the real error is swallowed,

github.com/microsoft/vscode

extensions/npm/src/tasks.ts

c2c01cfcf


      
          
          	for (const script of read.scripts) {
          		if (script.nameRange.start.isBeforeOrEqual(position) && script.valueRange.end.isAfterOrEqual(position)) {
          			return script.name;
          		}
          	}
          
          	return undefined;
          }
          
          export async function getScripts(packageJsonUri: Uri) {
          	if (packageJsonUri.scheme !== 'file') {
          		return undefined;
          	}
          
          	const packageJson = packageJsonUri.fsPath;
          	if (!await exists(packageJson)) {
          		return undefined;
          	}
          
          	try {

If you patch the extension locally, you get the “real error”,

cannot open file:///Users/Shared/Developer/workspaces/tilt/lmr/package.json. Detail: Files above 50MB cannot be synchronized with extensions.

which, actually, is also apparently incorrect / another red herring.

I ran through this with one of the agents, and they said it was related to a race-condition bug,

Your package.json is 506 bytes. The 50MB message is misleading.

It comes from Cursor’s MainThreadDocuments.$tryOpenDocument in workbench.desktop.main.js:

npm calls workspace.openTextDocument(package.json)
Main thread loads the file via createModelReference
It immediately checks _modelTrackers.has(uri)
If the tracker isn’t registered yet → throws the 50MB error
Trackers are added in handleModelAdded, which runs on a separate event. Race condition.

Your logs confirm this — error at 21:24:44, only ~1 second after Extension Host:user started at 21:24:43. npm scans before extension document sync is ready.

Steps to Reproduce

I’m not completely sure as sometimes it works and sometimes it breaks, with no changes to any file

Expected Behavior

All package.json files are supposed to be processed correctly and their tasks fill the NPM Scripts window

Operating System

MacOS

Version Information

Version: 3.9.16 (Universal)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Opus 4.8

Does this stop you from using Cursor

No - Cursor works, but with this issue

Colin · July 3, 2026, 12:22pm

Thanks @seaders!

This is a known bug. I’ve added your report to our existing bug report tracking this issue.

`anysphere.remote-wsl` deterministically rejects `openTextDocument` for certain WSL files with "Files above 50MB cannot be synchronized with extensions" — files are <2 KB, plain VS Code with `ms-vscode-remote.remote-wsl` on the same workspace works fine Bug Reports

Thanks, this is an important addition. Your reports show the issue is broader than we first thought. The symptom happens not only in WSL, but also in a local multi-root workspace on macOS and on bare-metal Ubuntu without any remote connection. That suggests the root cause isn’t anysphere.remote-wsl itself, but a more general path through FileSystemProvider and References. I’ve added this to the existing issue so the scope is expanded beyond WSL. There’s no fix yet, and I can’t share an ETA. The…

Are you able to use the tasks/scripts after manually opening the file?

seaders · July 3, 2026, 12:41pm

Sometimes, yes. In reading the other related thread, I’ve had that exact experience. If I time it right, opening a sub package.json, in infra/aws to be exact (which is one that can also create apparently 24k OTHER package.json files), it opens and then a second later, npm scripts has just popped back to fully working and the error gone. Sometimes I’ve edited the file, and it fixes it, but also, sometimes nothing has brought it back.

That just makes me think I just hadn’t opened the correct file that’s blowing up in the current session

Topic		Replies	Views
"Files above 50MB cannot be synchronized" on small local files in multi-root workspace (not WSL) Bug Reports extensions , macos , language-servers	1	49	May 22, 2026
Bug report 2: NPM task detection fails to parse valid package.json Bug Reports large-codebases , windows	7	144	June 10, 2026
`anysphere.remote-wsl` deterministically rejects `openTextDocument` for certain WSL files with "Files above 50MB cannot be synchronized with extensions" — files are <2 KB, plain VS Code with `ms-vscode-remote.remote-wsl` on the same workspace works fine Bug Reports extensions , wsl , language-servers , linear-linked	4	93	July 3, 2026
Opening cursor on a WSL repo sometimes has issues reading/writing files, has stale worktree read/write, and makes the ide entirely unsuable for writing, edits, chat, etc Bug Reports nightly , worktrees , wsl	5	93	June 15, 2026
Cursor Bug: Cursor extension terminated unexpeted 3 times within the last 5 minutes Bug Reports crashes , large-codebases	3	52	April 17, 2026