IntelliSense stuck on loading forever. There’s a popup saying the typescript server crashed and blaming the mdx extension but even after disabling it and restarting it doesn’t work. Downgraded to 3.9.16 (uninstall and re-install) and everything is working again. Disabled auto updates for now.
Steps to Reproduce
Install v3.10.11, open a typescript file.
Operating System
Windows 10/11
Version Information
Uninstalled so I don’t have the full version info, but that’s the version:
v3.10.11
Hey, thanks for the detailed report. Downgrading to 3.9.16 confirms it’s something that changed in 3.10.11.
I already dug a bit deeper: on macOS with the same 3.10.11, tsserver and IntelliSense work normally and I can’t reproduce the crash. So it looks Windows build specific, which is why your log is the key piece here.
No need to worry about mdx. That’s a generic VS Code message about a tsserver crash, it just lists extensions that have TS plugins. Since disabling mdx didn’t help, the cause is very likely in the TypeScript server itself, not the extension.
To dig further, I’ll need the crash log. If you can switch back to 3.10.11 for a bit, please collect the TypeScript Server log:
Open App Settings and set "js/ts.tsserver.log" to verbose, then restart Cursor.
Command Palette Ctrl+Shift+P → TypeScript: Open TS Server Log.
Open a TypeScript file and wait for the crash or hang.
Send the log contents here, or at least the last lines with the stack trace.
A couple quick questions to narrow it down:
Was the file opened from a normal local folder, or via SSH or remote?
Does it crash on any .ts file, or only in a specific project?
It was a normal local folder.
Crash on any ts file.
While I would like to help, I have work to do so I can’t switch back to 3.10.11 at the moment…
I’m attaching the working version details, in case it helps:
I’m seeing the same issue on macOS as well after upgrading to 3.10.11.
IntelliSense gets stuck on “Loading…” forever, and I can see tsserver[5.9.3]: semantic eating a lot of CPU in Activity Monitor / htop. Killing the tsserver process only helps temporarily; it starts again when opening TypeScript files.
Thanks for confirming, that matters. So it’s not just a Windows issue like I thought before, it also affects macOS.
Since you’re on 3.10.11 and can reproduce the crash, a log from your machine will be key. Can you collect the TypeScript Server log:
In App Settings set "js/ts.tsserver.log" to verbose, then restart Cursor.
Open Command Palette with Cmd+Shift+P, then run TypeScript: Open TS Server Log.
Open a .ts file and wait until it freezes or CPU spikes.
Paste the log here, or at least the last lines with the stack trace.
A couple of quick questions:
Was the file opened from a normal local folder, or via SSH remote?
Does it freeze on any .ts file, or only in a specific project?
About the bug itself, I confirmed an internal regression between 3.9.16 and 3.10.11. I can’t share an ETA for a fix yet, but the log will help us find the cause faster.
Confirmed on macOS too, and I managed to catch it live with full verbose tsserver logging on. Details:
Version: Cursor 3.10.17 (was 3.10.11 when I first posted — auto-updated since, issue persists), commit c89f45b83162…, VS Code API 1.125.0, Electron 40.10.3, Node 22.22.1 OS: macOS 26.5.1 (Darwin 25.5.0), arm64 Project: pnpm monorepo (pnpm 11.1.1), 31 tsconfig.json files across apps/*, packages/*, node_modules/.pnpm has 1,971 packages / 2,664 package.json files TypeScript: workspace version 5.9.3
Key finding: it’s not a live CPU spin, no tsserver.js process is even running while IntelliSense is stuck “Loading”. Looking at the verbose logs, the TS Server for a given tsconfig project dies *mid-loop while registering file watchers* for node_modules/.pnpm/*/package.json paths (module resolution “failed lookup location” watchers), then goes completely silent — no more log lines, no response, no crash message - and is never restarted. It’s scoped per-project: e.g. right now apps/dashboard and packages/api are dead/unresponsive while other projects in the same workspace are working fine. This matches reports of it being stuck on “some file types” but not others.
My guess: pnpm’s flat node_modules/.pnpm store means thousands of individual watcher registrations per project, and something in the 3.9.16→3.10.11 IPC/watcher-handling path now deadlocks under that load instead of just being slow. Separately, in earlier sessions today I also saw the TS Server crash-loop 14-32 times within a single ~7 minute window (rapid restart-and-die cycle) — possibly the same root cause, possibly a second bug.
I have verbose tsserver logs but they’re way too large to attach here (500MB-700MB per session from just a few minutes of crash-looping) and contain proprietary code/paths from a private repo, so I’d rather share relevant excerpts privately if useful - happy to DM specific snippets or a stack sample from a live hang if that helps narrow it down.
Thanks, this helps. A couple things that would narrow it down a lot, can you check?
TypeScript version. Your workspace is pulling TS 5.9.3, but Cursor has TS 6.0 built in. Switch to the built-in one and see if the bug goes away: Cmd+Shift+P → TypeScript: Select TypeScript Version → Use VS Code’s Version, then restart the TS server or restart Cursor. TS 6.0 has a bunch of fixes, so I’m curious if it still happens there.
Clean workspace. Does the freeze happen in a brand new empty folder with just one .ts file, or only in a pnpm monorepo? This helps tell if it’s tsserver itself or load from watchers on the flat .pnpm store.
Logs. I don’t need a full dump, but a targeted excerpt would really help, the last lines before the project goes silent, and the stack from a crash-loop session. Please DM me, with any proprietary paths redacted.
Right now the repro isn’t stable on all machines, some are fine on 3.10.18, so your answers to 1 and 2 are especially valuable.
TypeScript version
“Use VS Code’s Version” in my picker is actually 5.9.2, not 6.0. There’s no 6.0 option at all (only bundled 5.9.2 / workspace 5.9.3). So on my Cursor build (3.10.17), the bundled TS isn’t 6.0 — can’t test that specific version unless there’s a different channel/flag that ships it.
That said, I can answer the underlying question a different way: crash reporter shows the identical crash signature on both 5.9.2 and 5.9.3 (44 crashes on 5.9.2, 5 on 5.9.3 over the last 2 days, same signal every time). So whatever it is, it isn’t specific to the 5.9.x patch — switching between these two doesn’t change the outcome.
Logs
Turned on verbose typescript.tsserver.log and caught it live. This isn’t a silent hang, it’s a hard crash — syntax stays healthy the whole time, only semantic dies, every restart, ~20–45s after forking:
16:02:13.420 [info] Starting...
16:02:57.489 [error] TSServer exited. Code: null. Signal: SIGABRT <- 44s later
16:02:57.489 [info] Starting...
16:03:25.640 [error] TSServer exited. Code: null. Signal: SIGABRT <- 28s later
16:03:25.640 [info] Starting...
16:03:53.444 [error] TSServer exited. Code: null. Signal: SIGABRT <- 28s later
And the macOS crash reporter gives the actual native stack for that SIGABRT, which is a real V8 heap OOM, not a deadlock:
node::OOMErrorHandler -> v8::internal::V8::FatalProcessOutOfMemory
-> Heap::FatalProcessOutOfMemory -> Heap::CollectGarbage
-> HeapAllocator::AllocateRawWithRetryOrFailSlowPath -> abort()
Thread name on the crash: tsserver[5.9.x]: semantic. Live sampling right before a crash shows CPU 100% consumed by v8::internal::MarkingVisitorBase/ConcurrentMarking/Sweeper — it’s not stuck, it’s GC-thrashing until V8 gives up.
One more clue from the same log: each crash lines up with semantic processing an updateOpen restoring ~77 already-open tabs (full file content) across my 31-tsconfig project graph — so it looks like the OOM is triggered specifically by bulk session-restore load on a large multi-project pnpm workspace, not steady-state editing.
I have the log + crash reports ready to send but I’m getting “Sorry, you cannot send a personal message to that user” when I try to DM. How can I get these to you?
Hey, thanks for flagging this. There’s a bit of confusion here: the thread you linked (158633) is about a different issue. In that one, TypeScript “rolled back” because importing settings from VS Code pulled in typescript.tsdk, which pointed to an older TS version. Removing that key fixes it. That’s not related to the tsserver crash discussed in this thread.
This specific bug (tsserver crashes or IntelliSense gets stuck on “Loading” after 3.10.11) is separate and still being tracked. There’s no ETA for a fix yet. Downgrading to 3.9 is still a working workaround.
Based on the diagnostics in this thread, the cause looks like a V8 heap out of memory during session restore (lots of open tabs) in a large pnpm monorepo. A couple things to try if you don’t want to downgrade:
Increase tsserver memory limit: set typescript.tsserver.maxTsServerMemory (for example, 8192), then run TypeScript: Restart TS Server.
Close extra tabs before restarting Cursor, so session restore doesn’t load everything at once.
To confirm you’re hitting the same case, can you share:
Your OS and exact Cursor version
Whether this is a big monorepo (pnpm or yarn workspaces, lots of tsconfig) or a regular project
Whether it crashes on any .ts file or only in a specific project