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 …).
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
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.
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.
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:
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.
The VS Code version where it works (stable channel, insiders, exact build).
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.
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.
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
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.
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.
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.
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)
Confirm whether Cursor forked or extended npm task detection beyond VS Code (extra scans, different defaults, ignoring npm.autoDetect: "off", etc.).
Reproduce on a large pnpm monorepo on Windows with manifest rewrite churn — not only minimal single-line JSON.
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.
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.
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:
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".
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.
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.