Cursor sessions run on the server's main thread, so a wide Cursor fan-out stalls every other request #31022

Before submitting

• I searched existing issues and did not find a duplicate. Related but different: Server event loop freezes 6–28 s on a normal-sized database (5.9 GB), so remote devices lose Send #26224 and SQLite writes run on the server's event loop, so one slow transaction disconnects every client #30065 (event-loop stalls), History-wide reads saturate the single SQLite reader on large databases (thread switches take 12-50 s) #24895 (reader saturation), and [Bug]: Every git spawn blocks the server's event loop for longer as its memory grows (fork on Linux) #21289 (spawn cost on Linux). None of them covers where Cursor sessions run.
• I included enough detail to reproduce or investigate the problem.

Area

packages/provider-cursor, apps/server

What happens

The Cursor provider runs every Cursor agent inside the T3 server process. loadCursorSdk() loads @cursor/sdk into the server with createRequire. CursorAgentSdkRunner.open then calls Agent.create or Agent.resume in the same process. Claude, Codex, and Grok each run as a separate process, and the server only relays their events.

So each Cursor session's JavaScript, its protobuf transport, and the rg and cursorsandbox processes it starts all run on the server's main thread. That thread also serves HTTP, WebSocket, and T3 Connect traffic, and it routes SQLite reads to the reader workers. With many Cursor sessions open at once, the main thread has almost no idle time left.

Steps to reproduce

1. On Linux, run t3 serve with the Cursor provider signed in.
2. Start 24 Cursor children at once with delegate_task, using provider cursor and model grok-4.7 with default options. Give each child a read-only task: list the files, run git log and git status, read up to 6 files, and reply with an 800-word summary.
3. While the children run, record a CPU profile of the server's main thread. I sent SIGUSR1, then ran Profiler.start and Profiler.stop over CDP for 60 seconds.

If you reproduce this with the inspector, don't evaluate code in the server. I scheduled import('node:inspector').then((m) => m.close()) through Runtime.evaluate. The timer threw ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING, nothing caught it, and the server exited with code 1.

Expected behavior

A Cursor session costs the server's main thread about what a Claude or Codex session costs, which is relaying its events. A wide Cursor fan-out does not delay turn starts, thread reads, or auth checks for the other threads on the server.

Actual behavior

The profile covers 61.3 s and 37,377 samples, taken 5 minutes after a server restart:

I sampled main-thread CPU from /proc/<pid>/task/<pid>/stat every 5 seconds. It stayed between 58% and 96% while the 24 sessions ran. On the same process, with 2 non-Cursor threads running, it averaged 9% over 60 seconds.

The same thing happened earlier without a test. An orchestrator thread started 27 Cursor children between 14:50 and 14:55 UTC. The server traces for the following hour show:

• ProviderTurnStartService.start took a median of 46.6 s and up to 186 s.
• CursorAgentSdkSession.send inside CursorAdapterV2.startTurn took 1,033 s across 27 turn starts, about 38 s each.
• boot-service.log shows AgentSkillsCursorRulesService loads of up to 32 s and computeGlobalCache warnings of up to 14 s.
• Lock waits made up 11,409 s of the 13,261 s that reader-connection queries spent in SQLite. ProjectionStore.isNodeStored, a primary-key read, took a median of 146 ms in the server. The same read took 0.66 ms from a separate process on the same database. Each of the 4 reader worker threads had used about 3.5 minutes of CPU in 8.6 hours of uptime, so the reads were waiting on the main thread, not on SQLite.
• Main-thread CPU was 63% to 81% in five 2-second samples during that hour.

Possible fix

Run @cursor/sdk off the main thread, in a worker thread or a child process that owns the SDK. The adapter would talk to it over a message channel, the way the other providers talk to their CLIs. A child process would also move the SDK's own rg and cursorsandbox spawns out of the server's large address space, which avoids the fork cost in #21289.

Environment

• T3 Code 0.1.7-nightly.20261104.4151 (322f654), t3 serve as a systemd user service, with clients over T3 Connect
• Bundled Node v26.12.1 with libuv 1.52.1, and @cursor/sdk 1.2.0
• Linux 7.0.0-42-generic, 8 vCPU AMD EPYC 9645, 15 GiB RAM
• statev2.sqlite is 6.2 GB with 3 free pages
• main at 9e85538 has the same code in sdk.ts and CursorAgentSdk.ts

I can attach both .cpuprofile files.