Bug report 2: NPM task detection fails to parse valid package.json

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor repeatedly shows:

Npm task detection: failed to parse the file …\package.json
for files that are valid JSON on disk.
JSON.parse succeeds, scripts run fine in terminal, and the same workspace works in VS Code.

This looks like a detector/read-state failure (likely around file open/read timing), not actual JSON parsing.

Steps to Reproduce

Open a large pnpm monorepo on Windows (many workspace packages + many nested node_modules manifests).
Let Cursor auto-scan for NPM scripts.
Optionally run a high-churn script that updates many manifests quickly (example: pnpm refresh:bot-deps:all).
Observe toasts: failed to parse …\package.json, and NPM Scripts panel may be empty/stale.

Expected Behavior

False parse errors on valid files.
NPM Scripts sidebar becomes unreliable/empty.
Terminal execution still works (pnpm run …).

Operating System

Windows 10/11

Version Information

Cursor Version: 3.4.20 (system setup)
VSCode Version: 1.105.1
Date: 2026-05-15T02:26:10.351Z
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

Additional Information

I cannot share my production monorepo due to size and constraints, and I cannot provide a practical minimal repro because the issue appears tied to large-scale workspace/file-churn conditions.
Please investigate this directly in Cursor’s npm task detection path for large pnpm monorepos on Windows and other OS’s

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report and for coming back with a second thread that has more accurate context. The earlier reply in the thread missed the real root cause, sorry about that.

Quick summary: the failed to parse error in this case isn’t about JSON. That message is a generic catch in npm task detection code inherited from VS Code upstream. When openTextDocument() fails for any reason, it gets re-labeled as a parse error. In a large pnpm monorepo where manifests get rewritten often, your pnpm refresh:bot-deps:all is a classic trigger, you can hit a race between checking whether the file exists and reading it. pnpm can lock or rewrite the file right at that moment. So the JSON is valid on disk, but the scan trips.

A workaround that should stop the toasts and not get in your way:

"npm.autoDetect": "off"

Set it in User or Workspace settings. The NPM Scripts sidebar will stop auto-scanning, but pnpm run ... in the terminal will keep working as usual, which you said already works.

If you want to keep the sidebar partially, you can leave it on and add exclude patterns via npm.exclude for heavy folders with lots of churn.

About the underlying race condition: it’s tracked upstream in VS Code at Default npm package causes tasks to take a long time to start even when task detection is disabled · Issue #45816 · microsoft/vscode · GitHub and npm extension - check for root package.json before findFiles by nrayburn-tech · Pull Request #124803 · microsoft/vscode · GitHub, and there isn’t a full fix yet. On our side, we recently added a timeout plus cancellation for the task-provider RPC so scans won’t hang when they’re slow, but we haven’t changed the error text or the race itself yet. If the workaround doesn’t work for you for some reason, let me know and we’ll see what else we can do.

6

Thanks for the clarification. I tried the workaround already — npm.autoDetect: "off" and aggressive npm.exclude patterns — but it doesn’t actually resolve the issue on my side.

At this point I only have around ~10 scripts visible in the sidebar, and the errors still happen consistently. The interesting part is that the exact same repo works fine in VS Code the entire time. No parse toasts, npm scripts sidebar works normally there.

So this seems pretty Cursor-specific rather than just an upstream VS Code race condition. Especially because Cursor’s sidebar is actually much faster at discovering scripts than VS Code in this repo, it just becomes unusable because the scans eventually fail and the sidebar breaks.

For context, terminal execution is always fine (pnpm run ... works normally). The problem is specifically the npm scripts sidebar/task detection layer in Cursor.

Feels like Cursor may be doing task scanning more aggressively/concurrently than upstream VS Code, which makes the pnpm manifest rewrite race much easier to hit.

7

Thanks for the feedback on the workaround, that’s a useful signal. The comparison with VS Code on the same repo and machine is especially helpful, since it rules out the upstream race only hypothesis.

To dig further, can you share a couple more details:

  1. A screenshot or a snippet from your settings.json showing npm.autoDetect and npm.exclude, and which scope they’re set in (User or Workspace). I want to make sure the setting is actually applied, because with off the built-in npm task provider shouldn’t scan at all.
  2. The VS Code version where it works (stable channel, insiders, exact build).
  3. Logs from View > Output > Tasks (dropdown on the right) at the moment the toasts pop up. It usually shows which provider is crashing and on which file.
  4. Please confirm the VS Code test was on the same Windows machine, same repo state, at the same time, with Cursor closed.

In parallel, I’ve reported this to the team and mentioned the A/B test with VS Code and that the workaround didn’t help.

8

Thanks for the upstream links — I read them. I still think this is primarily a Cursor problem in my setup, not “the same as VS Code.”

What works vs what breaks

VS Code (same repo, same machine) Cursor
package.json on disk Valid JSON Valid JSON
pnpm run … in terminal Works Works
NPM Scripts sidebar Works, stable Fast at first, then parse toasts + sidebar breaks
npm.autoDetect: "off" N/A / not needed Tried — errors still happen
Aggressive npm.exclude N/A Tried — still ~10 scripts visible, errors continue

So this isn’t “invalid JSON” or “pnpm doesn’t work.” It’s Cursor’s npm task detection layer failing under load.

Why “upstream VS Code race” doesn’t explain my case

  1. Same repo, same OS, same pnpm churn — VS Code does not show the false parse toasts and the sidebar stays usable. If it were only the inherited VS Code race, I’d expect similar failure modes. I don’t.

  2. Workarounds that should disable scanning don’t fix it — You suggested npm.autoDetect: "off". I already use that plus heavy npm.exclude. I still get failed to parse …\package.json and a broken/stale sidebar. That points to something in Cursor still scanning or re-triggering detection, not just the stock VS Code path with auto-detect off.

  3. Cursor behaves more aggressively, not less — Script discovery in Cursor is faster than VS Code on this monorepo, which suggests more concurrent / broader scanning. That would amplify any read-during-write race when manifests are rewritten (e.g. pnpm refresh:bot-deps:all), even if the generic error message comes from upstream code.

  4. The error message is misleading, but the bug is real — I accept that “failed to parse” may be a catch-all when openTextDocument() fails. The issue is why Cursor hits that path so often on valid files that Node/JSON.parse and VS Code handle fine.

My environment (for your repro team)

  • Large pnpm monorepo (many workspace packages + nested package.json under node_modules)

  • Windows (reported build: Cursor 3.4.20, VS Code 1.105.1)

  • High churn: scripts that rewrite many manifests quickly

  • Terminal: always fine; only sidebar / npm task detection is broken

What I need from Cursor (not generic upstream deferral)

  1. Confirm whether Cursor forked or extended npm task detection beyond VS Code (extra scans, different defaults, ignoring npm.autoDetect: "off", etc.).

  2. Reproduce on a large pnpm monorepo on Windows with manifest rewrite churn — not only minimal single-line JSON.

  3. Fix or gate the scanner in Cursor: respect npm.autoDetect: "off", backoff/retry on transient read failures, don’t toast “parse” for I/O races, exclude node_modules/**/package.json by default in monorepos.

  4. Until fixed: a Cursor-specific setting to fully disable npm script discovery (not just upstream behavior).

Bottom line: Valid JSON, working terminal, working VS Code on the same project → this is a Cursor IDE reliability bug, not something I can fix in my repo. Please treat it as Cursor-side investigation, not closed as “upstream won’t fix it.”

Happy to provide version/build logs or a sanitized tree layout if that helps — I can’t ship the full private monorepo.

9

Thanks, the comparison with VS Code on the same repo and the same machine is a strong argument, and I agree we shouldn’t close this as upstream won’t fix. The point about npm.autoDetect: "off" is especially interesting. If the failed to parse toasts still show up with that setting off, something is still triggering detection. That would be Cursor-side behavior, not a pure upstream race. That’s the lead we need to confirm.

To give the team something reproducible, not just a description, I’m still missing a couple things from the last request. Without them we can’t move forward:

  1. The log from View > Output > Tasks at the moment the toasts appear. It shows which provider fires and on which file. That’s exactly what will tell us if something is scanning even with autoDetect: "off".
  2. Your settings.json and the scope where npm.autoDetect and npm.exclude are set, User or Workspace. I want to confirm the setting actually applied.
  3. The exact VS Code build where everything works, stable or insiders plus the version, and confirmation the test was on the same Windows machine, same repo state, with Cursor closed.

In parallel, try one more workaround that’s broader than npm:

"task.autoDetect": "off"

This gates all task auto-detection, not just the npm provider. If the toasts disappear with this but not with npm.autoDetect: "off", that’s an important signal that detection is being triggered by a different path than the one we disabled.

A sanitized workspace tree layout (your workspace package structure without any private code) would also help the repro team build a similar-shaped monorepo. Please share the Tasks log first and we’ll start from there.

10

Thanks for the follow-up. Here is everything requested, with paths and repo details redacted.

Cursor build

Field Value
Version 3.7.12
VS Code Extension API 1.105.1
Commit b887a26c4f70bd8136bfffeda812b24194ec9ce0
Date 2026-06-05T01:45:12.918Z
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 Linux x64 6.5.0-14-generic

1. Tasks output log (at failure time)

View → Output → Tasks (before workaround):

Error: Npm task detection: failed to parse the file /home/[REDACTED]/Documents/GitHub/[REDACTED]-monorepo/package.json

Activating task providers npm

Error: Npm task detection: failed to parse the file /home/[REDACTED]/Documents/GitHub/[REDACTED]-monorepo/package.json

Notes:

  • Failure is on the repo root package.json, not a nested workspace package.
  • Activating task providers npm appears between errors → npm task provider is still activating/scanning.
  • Terminal pnpm run … works on the same file; JSON.parse / Node read the file fine.

After workaround (task.autoDetect: "off", see below): Tasks output is quiet — no repeat parse toasts. NPM Scripts sidebar is empty (expected with auto-detect off).

2. Settings + scope

User (~/.config/Cursor/User/settings.json) — currently:

{
  "explorer.confirmDelete": false,
  "cursor.inlineDiff.enablePerformanceProtection": false,
  "window.autoDetectColorScheme": false,
  "task.autoDetect": "off"
}

Workspace: no .vscode/settings.json in the repo (no folder-level overrides).

Previously tried (not in active settings when errors occurred):

  • "npm.autoDetect": "off" — errors still appeared (or sidebar still broke).
  • Aggressive "npm.exclude" (e.g. **/node_modules/**, **/packages/**, legacy app paths) — ~10 scripts still visible, errors continued.

Currently applied workaround: "task.autoDetect": "off" at User scope only.

Setting Before errors Now (workaround) Scope
npm.autoDetect default (on) / also tried "off" not set User
npm.exclude tried aggressive list not set —
task.autoDetect default (on) "off" User

VS Code comparison not completed yet on this machine. I can follow up with Stable/Insiders version + same-repo test if needed.

4. task.autoDetect: "off" workaround result

With "task.autoDetect": "off" (User) Result
Parse toasts in Tasks output Stopped (quiet after reload)
NPM Scripts sidebar Empty (no auto-discovery)
Terminal pnpm run … Works

Signal: Disabling all task auto-detection fixes the false “failed to parse” toasts. Disabling only npm.autoDetect did not (in my earlier attempts). That suggests detection is triggered on a path broader than the npm setting alone — worth confirming on Cursor’s side whether something beyond stock VS Code npm detection still scans manifests.

5. Environment & repo shape (sanitized)

  • Package manager: pnpm 10.33.0 (packageManager in root manifest)
  • Monorepo: pnpm workspaces + Turborepo
  • Node: .nvmrc → 20 (IDE Node 22.22.1 per About)
  • Workspace manifests (excluding node_modules): ~81 package.json files
  • Root manifest: ~72 npm scripts; valid JSON; includes large pnpm.overrides block

Sanitized tree:

[REPO_ROOT]/
├── package.json                 ← errors point here
├── pnpm-workspace.yaml
├── turbo.json
├── apps/
│   └── [single-electron-app]/
├── packages/                    (~60 shared packages)
└── modules/
    ├── ad-traffic/              (+ engine subpackages)
    ├── search-traffic/
    └── soundcloud/

pnpm workspace globs: packages/*, apps/*, modules/*, modules/ad-traffic/engines/*

High-churn scripts that rewrite many manifests quickly (possible read-during-write races):

  • sync:bot-deps / sync:bot-deps:force — refreshes shared bot runtime pool / junction node_modules
  • sync:bot-packages — regenerates */bot/package.json from a central manifest
  • lint:workspaces — applies lint scripts across workspace packages
  • sync:lockfile — pnpm install --lockfile-only

Summary

Valid root JSON, working terminal, broken/unstable NPM Scripts discovery in Cursor — false “failed to parse” on the root manifest. task.autoDetect: "off" stops the toasts but leaves the sidebar empty; npm.autoDetect: "off" + heavy npm.exclude did not reliably fix it.

Please treat this as Cursor-side investigation (scanner / race / misleading error message), not invalid repo JSON. Happy to provide additional Tasks logs, a sanitized directory listing, or a screen recording on request — I cannot share the full private monorepo.

11

Thanks, this is exactly what we needed. The key point from your data is:

task.autoDetect: "off" stops the toasts, while npm.autoDetect: "off" plus npm.exclude does not. That’s a strong signal that task detection on your setup is being triggered through a broader path than the stock npm provider. Otherwise, turning off npm.autoDetect would have stopped the scanning. Also, the error consistently points to the root package.json, and in the log between errors you can see Activating task providers npm. I sent this to the team along with the Tasks log, the workaround matrix, and the repo form details (pnpm workspaces plus Turborepo, about 81 manifests, large pnpm.overrides).

One more note: in your new About info you’re now on Linux x64 and Cursor 3.7.12, while before it was Windows and 3.4.20. So this isn’t Windows-specific and it reproduces cross-platform. Good that we confirmed that.

What’s still missing to fully close the Cursor-specific vs upstream question is the VS Code A/B test on this same Linux machine. When you have a minute, please repeat the same test on the same machine, with the repo in the same state, and with Cursor closed. Share the VS Code channel and exact version (Stable or Insiders plus build), and whether you see the same toasts on the root manifest. That will confirm whether this behavior is specific to Cursor.

For now, the workable interim is to keep task.autoDetect: "off". The toasts go away, running pnpm run ... in the terminal still works, and the Tasks sidebar will be empty. I can’t share an ETA for a fix yet, but the bug is logged, and I’ll update this thread as soon as we have news.