Cursor private workers accumulate across closed workspaces — missing lifecycle ownership and release mechanism

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor private workers can accumulate across workspaces; ownership and safe-release state are not exposed
Product: Cursor IDE — built-in cursor-agent-worker extension / My Machines private workers
Environment: macOS 27.0.1 (arm64); Cursor 3.24.18 stable (be4c9e5350d77747b42cd467cbd3370a753d4640); anysphere.cursor-agent-worker 0.0.1; agent CLI 2026.10.14-941492e
Area: Background agents / My Machines / workspace lifecycle / resource usage
Summary
Private workers are designed to persist after a Cursor window closes: a My Machines worker may still be available for remote agents or automations. Multiple workers for one repository—or even one checkout—may be legitimate.
The issue is that workspace workers can remain running for long periods, while the client does not expose enough ownership, reservation, or consumer information to determine when a worker is no longer needed. On one development Mac, approximately 31 private-worker processes accumulated during normal use of temporary Git worktrees, collectively consuming approximately 1.4 GB of resident memory. Some had been running for approximately 12 days. These measurements establish resource accumulation, not that every worker was abandoned.
An external cleanup script cannot safely distinguish a worker intentionally waiting for a future My Machines assignment from one whose workspace and consumers are gone. We deliberately did not automate termination.
How to reproduce / inspect
These steps illustrate the persistence and observability gap; they do not, by themselves, prove that any individual worker is abandoned.

  1. Use Cursor with My Machines / private-worker availability enabled.
  2. Open a temporary Git worktree in its own Cursor workspace window.
  3. In Cursor’s Agent Worker output channel, note the worker’s startup and process ID (Started daemon or Attached to existing daemon).
  4. Close that workspace window without disabling private-worker availability or scheduling any known work against that checkout.
  5. Observe that the cursor-agent worker start process can remain running after the window closes.
  6. Repeat with other temporary workspaces over time, and observe the number of persistent private-worker processes.
  7. Inspect the local worker status interface. It can report READY / CLAIMED and a claimed flag, but it does not identify the consuming agent, automation, or session, or distinguish an explicitly reserved My Machines worker from one safe to retire.
  8. Leave the worker idle for longer than one hour. In this client configuration, the normal 3,600-second idle-release default is overridden with 0.
    Privacy note: Avoid sharing raw process command lines or unreviewed local logs in public replies. Sanitized diagnostics can be provided if needed.
    Expected behavior
  • Legitimate remote agents, automations, and explicitly persistent My Machines workers survive window closure.
  • Cursor tracks or otherwise reconciles ownership and persistent reservations for each worker.
  • Workers with no remaining consumers and no persistent reservation are released after a documented grace period.
  • Users can inspect worker state and safely retire workers through a supported UI or CLI action.
  • Multiple valid workers associated with the same repository or checkout remain supported.
    Observed client behavior and evidence
    Confirmed by inspection of the installed client/CLI:
  • The built-in extension launches cursor-agent worker start as a detached child and unref()s it.
  • It sets CURSOR_WORKER_IDLE_RELEASE_TIMEOUT=0. The CLI documents a default of 3600 seconds, with 0 disabling idle-based release; other release mechanisms may still exist.
  • The extension’s deactivate() path does not terminate the worker; the local extension can later reattach to an existing daemon.
  • GetWorkerId exposes a worker ID. The WatchStatus schema exposes coarse state such as READY, CLAIMED, connected, and claimed, but not a consumer identity, future automation reservation, or safe_to_stop determination.
  • The worker handles SIGTERM gracefully. Signal handling is not the obstacle; knowing whether a signal is appropriate is.
    Observed / recorded on this workstation:
  • Approximately 31 workers, approximately 1.4 GB combined resident memory, and individual lifetimes of up to about 12 days before manual shutdown.
  • Several older workers were associated with historical temporary worktree checkouts.
  • Logs showed existing daemons being reattached to, rather than replaced, when their workspaces were revisited.
  • Following manual shutdown, an independent dry-run inventory showed:
    running=1
    already_stopped=33
    historical_checkouts_not_running=15
    proposed_terminations=0
    signals_sent=0
    For the remaining live worker, the auditor recorded remote-agent, automation, and background-session status as unknown, and preserved the process.
    Limits of this evidence: The status-field assessment is based on the installed CLI’s interface definitions; a live WatchStatus response was not independently captured. We cannot tell from local evidence whether Cursor has a richer server-side claim registry or whether some of the older workers were intentionally reserved. Persistence after window closure is not itself a bug.
    User impact
  • Memory and background-process accumulation during extended multi-worktree development.
  • Live workers can keep retired checkout directories in use, complicating worktree cleanup.
  • Users lack a reliable way to determine which private workers can be retired without disrupting background functionality.
  • A heuristic cleanup based on age, CPU use, parent PID, closed windows, or missing directories risks terminating legitimate remote work.
    Proposed direction for Cursor engineering
    This is a suggested architecture, not an assertion about Cursor’s server internals:
  1. Ownership / reservation state: Associate each worker with current local-workspace, remote-agent, automation, background-session, and explicit persistent-availability requirements.
  2. Safe release: Gracefully retire a worker after the last requirement disappears, provided it is not intentionally persistent.
  3. Introspection: Expose useful ownership or reservation information (or an authoritative safe_to_stop result) through supported product controls/API.
  4. Reconciliation: Reconcile surviving processes and worker registrations after window closure, extension-host failure, and application restart.
  5. User control: Provide a supported list-and-retire action that refuses to stop workers still needed by remote or scheduled work.
    Simply killing workers when a window closes, limiting workers to one per repository, or restoring a timeout without accounting for intentional My Machines availability would be unsafe.
    Questions for Cursor
  6. What is the intended lifecycle for a private worker whose original workspace window and checkout are gone but whose My Machines registration remains?
  7. Does Cursor already maintain server-side worker ownership or future reservations that the local client does not expose?
  8. Is there a supported way to inspect those reservations and safely retire a specific worker?
  9. What release/reconciliation mechanism is expected to prevent indefinite accumulation when private-worker availability remains enabled?
    Suggested acceptance criteria
  • An unclaimed, non-persistent worker exits after a documented grace period; a deliberately persistent My Machines worker does not.
  • Remote agents and automations survive window closure and recover correctly after restarts.
  • Multiple legitimate workers per repository or checkout remain supported.
  • Cursor exposes an authoritative worker-retirement state or safe stop control.
  • Repeated temporary-workspace creation and application restarts do not cause indefinitely increasing worker counts when no ongoing consumers or reservations remain.
    Additional sanitized technical evidence is available on request. No raw diagnostics or private project information are attached.

Steps to Reproduce

  1. Launch Cursor with My Machines / private-worker availability enabled.

  2. Open a temporary Git worktree in its own Cursor workspace.

  3. Open Cursor’s “Cursor Agent Worker” output channel and record the worker PID from the “Started daemon” message.

  4. Close the workspace window without explicitly disabling private-worker availability.

  5. Observe that the cursor-agent worker process can remain running after the workspace closes.

  6. Repeat with additional temporary workspaces. Multiple persistent private-worker processes may accumulate.

  7. Inspect the local worker API. GetWorkerId returns the worker ID, while WatchStatus exposes READY/CLAIMED and a claimed boolean. Neither exposes the identity of remote agents, automations, or background sessions using the worker.

  8. Leave the workers idle for longer than one hour. The extension sets CURSOR_WORKER_IDLE_RELEASE_TIMEOUT=0, disabling the CLI’s normal 3600-second idle release.

The persistence itself may be intentional. The reproducible issue is that Cursor does not expose sufficient ownership or reservation information to distinguish workers intentionally available for future work from workers that can safely be released.

Expected Behavior

Cursor should maintain explicit lifecycle ownership for private workers.

Workers serving remote agents, scheduled automations, or My Machines availability should remain running as intended.

Workers with no remaining consumers and no explicit persistent reservation should be gracefully released after an appropriate grace period.

Cursor should expose enough worker state to distinguish these cases, including active claims, persistent reservations, and whether shutdown is safe.

Closing and reopening temporary workspaces, or restarting Cursor, should not cause indefinite accumulation of workers that are no longer needed.

Multiple legitimate workers associated with the same repository must remain supported.

Operating System

MacOS

Version Information

Cursor: 3.24.18 (Stable)
Commit: be4c9e5350d77747b42cd467cbd3370a753d4640
VS Code base: 1.128.0
OS: macOS 27.0.1 (26A434), arm64
Extension: anysphere.cursor-agent-worker 0.0.1
Agent CLI: 2026.10.14-941492e

For AI issues: which model did you use?

Not model-specific.

This is a Cursor IDE private-worker lifecycle issue involving the built-in cursor-agent-worker extension. It occurs independently of the selected AI model.

Additional Information

This issue was discovered during intensive development involving multiple Git worktrees and background agents. Approximately 31 persistent private-worker processes accumulated over 12 days, consuming roughly 1.4 GB of RAM.
We investigated a local cleanup utility but determined that Cursor does not expose sufficient information to safely identify workers that are no longer needed. Automatic termination was therefore deliberately rejected.
We can provide additional sanitized technical evidence, including extension lifecycle findings and worker shutdown logs, if useful to Cursor engineering.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @Zach_Azeez, thanks for the detailed report.

You’ve read the current behavior correctly. Cursor starts one worker per project folder you open (each temporary worktree counts as its own folder) and keeps it running after the window closes, so agents can still reach that folder. The idle timeout is turned off on purpose for the same reason. Right now nothing retires a worker once its folder is no longer in use, so with frequent worktrees they pile up. I’ve passed this to the team.

To your questions:

  1. There’s no separate long-lived reservation behind these workers. The only thing that ties a worker to work is an agent run that is actively assigned to it.
  2. There isn’t a supported list-and-retire action yet.
  3. If no agent is currently running in a folder, stopping that folder’s worker is safe. It starts again the next time you open that folder in Cursor. If an agent is running on it, that run waits for the worker to come back rather than failing.

If you’d rather have Cursor clear them than signal them yourself, signing out of Cursor and back in should stop all of your workers on that machine. Only the folders you have open get a worker again. Turning off Remote Control isn’t a reliable way to stop them at the moment, so I wouldn’t count on that.