Extension host VAS in Cursor 3.15.6

On a shared server my extension host went into a crash loop after 3.15.6 update. The diagnosis was that the extension host is now reserving >80+GB of VAS and I am hitting a user limit set in limits.d config of 96GB. Result is extension host crash. Logs:

thread ‘gix_status::index_as_worktree’ panicked at gix-features/src/parallel/in_parallel.rs:83:22:
valid name: Os { code: 11, kind: WouldBlock, message: “Resource temporarily unavailable” }

thread ‘gix::status::index_worktree::producer’ panicked at gix-status/…/mod.rs:333:86
thread ‘’ panicked at gix/src/status/iter/mod.rs:269:56

Rayon: detected unexpected panic; aborting

Extension Host Process exited with code: null, signal: SIGABRT.

The resolution was to set the following environment (eg in ~/.bashrc):

export MALLOC_ARENA_MAX=2
export RAYON_NUM_THREADS=4

This is holding ext host VmPeak to around 75GB and now it’s not crashing for me.

Can someone at Cursor confirm this diagnosis and advise, should I ask my admin to increase VM limit because the extension host needs a lot of VAS. Even now with the above fix there is not much headroom.

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.


Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!


Expected Behavior
What is meant to happen here that isn’t working correctly?


Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)


Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)


For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…


Additional Information
Add any other context about the problem here.


Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

This is a cursor session on remote host via ssh. Here are some details (after applying the above environment variable fix).

---- OS / kernel ----
os: Ubuntu 22.04.4 LTS
kernel: Linux 5.15.0-179-generic x86_64 GNU/Linux
libc: ldd (Ubuntu GLIBC 2.35-0ubuntu3.13) 2.35

-— CPU ----
cores(nproc):128 online=128
CPU(s): 128
Model name: Intel(R) Xeon(R) Gold 6338N CPU @ 2.20GHz
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 2
NUMA node(s): 2

-— Memory ----
total used free shared buff/cache available
Mem: 755Gi 57Gi 23Gi 33Mi 674Gi 693Gi
Swap: 0B 0B 0B

-— ulimits (current shell) ----
nproc(-u) soft=20000 hard=20000
as(-v,KB) soft=100663296 hard=100663296
rss(-m,KB) soft=100663296 hard=100663296
nofile(-n) soft=1048576 hard=1048576
stack(-s,KB) soft=8192 hard=unlimited

-— system limits.d (nproc / address-space caps) ----
/etc/security/limits.d/limit-ram.conf:6:* hard rss 100663296
/etc/security/limits.d/limit-ram.conf:7:* hard as 100663296
/etc/security/limits.d/limit-nproc.conf:10:* soft nproc 20000
/etc/security/limits.d/limit-nproc.conf:11:* hard nproc 20000

-— kernel task/thread limits ----
threads-max=6187906 pid_max=4194304 max_map_count=65530
your real-uid threads=660 processes=49

-— Cursor server build ----
path: /users/friedman/.cursor-server/bin/linux-x64/a1f686545fd0ce8917bbd2449f733551a9bce420/
installed: 2026-08-07 19:28:06.319488570 -0700
“version”: “1.1.3”
“version”: “1.93.0”
“version”: “1.0.9”
“nameLong”: “Cursor”
“version”: “3.15.6”
“commit”: “a1f686545fd0ce8917bbd2449f733551a9bce420”

-— MALLOC / RAYON env (mitigation) ----
MALLOC_ARENA_MAX=2
RAYON_NUM_THREADS=4

-— live extension host VmPeak vs address-space cap ----
pid 1643665: VmPeak=74.9 GiB threads=149 (78% of 96 GiB cap)
pid 1682607: VmPeak=71.9 GiB threads=141 (75% of 96 GiB cap)

Additional details:

The workspace is SONiC ( GitHub - sonic-net/sonic-buildimage: Scripts which perform an installable binary image build for SONiC · GitHub ), cloned using --recurse-submodules, so it’s a big workspace.

To reproduce, simply clone the workspace on the server and open the workspace in Cursor after connecting via ssh, with similar memory limit:
/etc/security/limits.d/limit-ram.conf:6:* hard rss 100663296
/etc/security/limits.d/limit-ram.conf:7:* hard as 100663296

The extension host crashes constantly which renders Cursor unusable.

Hey Barry, thanks for the detailed write-up. Your MALLOC_ARENA_MAX=2 + RAYON_NUM_THREADS=4 workaround is a solid short-term fix. For large shared remotes, also try turning off Index Repositories for Instant Grep in Cursor Settings (that’s the kill switch that usually stops this class of crash).

What you’re seeing isn’t caused by anything in your setup - we’ve let the team know and this is an issue we’re tracking. I’ll post here when there’s an update.