Remote extension host memory grows unboundedly over long agent chats; RPC reply handlers leak

Support Bug Reports
, , , ,
1

Describe the Bug

Summary

In long-running remote agent chats that issue many tool/MCP calls, the
remote extension host process grows to tens of GB of virtual memory
and the chat becomes unusably slow (~30 s pre-tool delays on every
message). Killing the extension host fully resolves the slowdown; on
reconnect a fresh extension host is created with normal memory and
latency. The same machine has been used with short chats without issue,
and the slowdown grows monotonically over the lifetime of a single
agent session.

The most plausible root cause based on logs is a leak of RPC
reply-handler callbacks in the agent ↔ extension-host channel: the log
shows a monotonically increasing counter of
RequestStore#acceptReply was called without receiving a matching request warnings throughout the session.

Environment

Remote: Ubuntu 24 (noble), Linux 6.8, 20 cores, 64 GB RAM

Connecting from Cursor Desktop over SSH/remote

Workspace: a moderately large Python repo (/root/poly)

No user-installed extensions (~/.cursor-server/extensions/ is
empty apart from extensions.json). All loaded components are
Cursor-first-party.

MCP servers configured: plugin-stripe-stripe, snapshot-push,
canonical-cache, plus built-in MCP logs.

Observed symptoms

Initial 30 s delay between submitting a message and the first tool call. Grew over the session.

SSH connection latency to the same host: <10 ms (i.e. not a network issue).

Restarting the remote agent connection instantly resolves the slowdown.

Evidence

  1. Bloated extension host (smoking gun)

At the time of the freeze, after ~3 h 22 min of active agent use:

PID RSS VSZ %CPU ELAPSED CMD
646333 419 MB 68,690,820 KB 14.6 03:18:24 node … --type=extensionHost

All agent tool shells in the session were direct children of this
extensionHost (pid 646333), so every tool invocation pays a
fork()-from-68 GB-VSZ cost — consistent with the observed ~30 s
pre-tool latency once it had grown.

After killing pids 646333 + 646282 and reconnecting:

Mem used: 52 GiB → 5.8 GiB (free 1 GiB → 50 GiB)

Most of the recovered memory came from the extension host.

  1. Monotonically growing RequestStore warnings

From /root/.cursor-server/data/logs//remoteagent.log:

2026-05-17 16:08:21.540 [warning] RequestStore#acceptReply was called without receiving a matching request 49
…
2026-05-17 21:00:33.887 [warning] RequestStore#acceptReply was called without receiving a matching request 240

Count in this session: 192 warnings, spanning ~4 h 52 min.

The integer is monotonically increasing — these are unique request
IDs whose replies arrived after the requestor was cleaned up. Each
one is a strong indicator of an orphaned response handler on one
side of the RPC channel.

The 192 leaked-reply events line up with hundreds of tool calls /
MCP calls made during the session.

  1. Repeated extension-host restarts in a single day

/root/.cursor-server/data/logs/20260517T155842/ contains:

exthost1 (15:58) – first ext host, died ~10 min in
exthost2 (16:08) – replaced exthost1
exthost3 (21:19) – this is the one I killed at 00:41
exthost4 (00:43) – fresh after manual kill+reconnect

So the remote ext host died/was replaced 3 times before today’s manual
intervention. Errors at death time in exthost3/remoteexthost.log
were just shutdown noise:

[error] EEXIST: file already exists, open ‘…/vscode.lock’
[error] [ExtHostCursorExplorerProviderService] Main thread provider unregistration failed Canceled
[error] Canceled: Canceled

Steps to Reproduce

Just use cursor and it becomes unusable.

Operating System

Linux

Version Information

Version: 3.4.20
VSCode Version: 1.105.1
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310
Date: 2026-05-15T02:26:10.351Z
Layout: glass
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.17.0-23-generic

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

This is a very thorough report. Two performance improvements that directly address extension host memory growth during long agent sessions have been merged to our development branch:

  1. Backpressure on agent-exec streaming RPC — keeps the extension host responsive during heavy tool call sequences

  2. Metrics IPC batching reduction — the metrics handler was flushing up to 20,000 entries per cycle, causing significant memory churn over long sessions. This has been cut dramatically.

These improvements are in our nightly builds but haven’t shipped to stable yet. Your build (3.4.20) doesn’t include them. They should land in the next stable release.

In the meantime, your workaround of killing the extension host and reconnecting is correct. You can also try Cmd/Ctrl+Shift+P > Developer: Restart Extension Host periodically (e.g., every hour or two during long sessions) to keep memory in check without fully disconnecting.

One note on the RequestStore#acceptReply warnings: those are expected after extension host restarts (the counter resets, so replies to pre-restart requests arrive “unmatched”). They’re a few KB of retained closures at most and not the memory driver here.

If you’d like to test earlier, you can switch to the Early Access release track in Cursor Settings > Application > Release Track. That should get you a build with these improvements sooner. Let us know if the issue persists after updating.