Bug Report: anysphere.remote-containers forwarder.js causes severe CPU drain via kubectl polling accumulation

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The forwarder.js implementation in the Remote Containers extension has two compounding issues that cause severe CPU degradation on the local machine:

  1. Per-forwarder kubectl polling: Each port forwarder spawns its own kubectl get pod … -o json every 1 second to monitor pod liveness. This polling runs independently per forwarder rather than being shared.
  2. Zombie localhost:0 forwarders on EADDRINUSE fallback: When a port forward (e.g., localhost:32903) fails with EADDRINUSE (because another Cursor window already holds that port), the extension spawns a fallback forwarder on localhost:0 (OS auto-assigned port). These fallback forwarders are not cleaned up when the window is closed, and each one continues its 1-second kubectl polling indefinitely.

What happened

I work with Kubernetes pods and frequently open the same pod in multiple Cursor windows (for worktrees, PVC inspection, etc.). Over time, localhost:0 fallback forwarders accumulated silently.
When I investigated, 26 zombie forwarders were running, each executing kubectl get pod every second — meaning 26 kubectl processes were being spawned per second. CPU idle had dropped to ~17%.
After manually killing the 26 forwarders, CPU idle recovered to ~53%. However, 2 forwarders immediately respawned — traced to 2 currently open windows, confirming the active reproduction path.

Evidence from logs

The EADDRINUSE → localhost:0 fallback sequence is visible in the Remote - Dev Containers extension logs. Fixed port forward fails with EADDRINUSE, immediately followed by a localhost:0 forwarder being spawned.

Root cause location
~/.cursor/extensions/anysphere.remote-containers-1.0.32/dist/scripts/forwarder.js

Steps to Reproduce

  1. Open a Kubernetes pod in Cursor window A. Ports (e.g., 32903 and 8000) are auto-forwarded.
  2. Open the same pod in Cursor window B. The extension attempts to forward the same ports, hits EADDRINUSE, and spawns localhost:0 fallback forwarders.
  3. Close window B. The fallback forwarders remain alive with their kubectl polling.
  4. Repeat steps 2–3 several times (or simply open/close windows over days of normal use).
  5. Observe CPU usage climbing as zombie forwarders accumulate.

Expected Behavior

  • Forwarders spawned by a window should be terminated when that window closes.
  • Pod liveness monitoring should use kubectl get pod --watch (or the Kubernetes watch API) instead of polling every 1 second.
  • Pod liveness monitoring should be shared across forwarders, not duplicated per-forwarder.
  • If a port is already forwarded by another window, the extension should detect this and skip the redundant forward rather than falling back to localhost:0.

Operating System

MacOS

Version Information

anysphere.remote-containers extension (v1.0.32)
Cursor Version: 2.6.22

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The root cause analysis, exact file location, repro steps, it’s all there. This is really great debugging.

The issue is clear: forwarder.js isn’t cleaning up the localhost:0 fallback forwarders when the window closes, and the per-forwarder polling with kubectl get pod every second makes it worse.

I’ve shared this with the team. There isn’t a specific timeline yet, but your report will help with prioritization. The child process lifecycle management issue on window close also shows up in other contexts, so it’s on our radar.

As a temporary workaround, periodically check for and kill the zombie forwarders manually, for example pkill -f forwarder.js or via Activity Monitor. Not ideal, but it should prevent them from piling up for now.

Let me know if you find anything else.