Critical: Recursive Cursor CLI agent spawning caused ~318M tokens of usage in 33 minutes

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

On October 16, 2026, a routine read-only investigation using Cursor Agent appears to have triggered unintended recursive agent execution, resulting in approximately 318 million tokens of usage within 33 minutes.

My remaining usage allowance dropped from 63% to 40% during this period.

Due to a suspected issue with Cursor CLI, the agent automations list command appears to have been incorrectly interpreted as an AI prompt rather than a CLI subcommand, unintentionally launching additional agent sessions.

Some of these agents appear to have executed similar commands, potentially triggering further agent sessions in a cascading loop.

Local forensic analysis revealed:

  • 293 new agent chats within approximately 40 minutes
  • 139 sessions starting with the same automations list prompt
  • Approximately 217 CLI invocations estimated from child-session terminal logs
  • 376 usage records, totaling approximately 317.7 million tokens
  • 95.2% of the recorded tokens were cache reads

The parent agent had explicitly been instructed not to use the problematic CLI command, but attempted it multiple times.

The exact parent-child process relationships have not yet been established, but the local evidence strongly suggests unintended cascading agent execution.

This was not an intentional request to launch hundreds of agents.

Steps to Reproduce

I have not intentionally reproduced this issue because doing so could trigger further excessive token consumption.

The suspected sequence, based on existing logs, is:

  1. Use Cursor CLI in an environment where the automations list subcommand is unavailable or not recognized.
  2. Have an existing Cursor Agent invoke agent automations list.
  3. The CLI may incorrectly interpret automations list as an AI prompt and launch a new agent session.
  4. The newly launched agent may attempt similar CLI commands, potentially creating additional agents recursively.
  5. This may result in repeated tool calls, excessive cache-read activity, and unusually high token usage.

These are inferred reproduction conditions, not independently verified reproduction steps.

I can provide relevant redacted session and terminal logs upon request.

Expected Behavior

  • An unavailable or unsupported CLI subcommand should return a clear error rather than unexpectedly starting an AI agent.
  • Cursor Agent should follow explicit instructions not to execute a specified command.
  • Agent-initiated CLI calls should not cause uncontrolled recursive agent execution.
  • Appropriate safeguards should prevent unexpectedly large numbers of agent sessions and excessive token consumption.

Operating System

Windows 10/11

Version Information

CLI Version: 2026.10.14-941492e
Model: Composer 2.5
Subscription Tier: Pro
OS: Linux (x64) / WSL2 on Windows
Terminal: Windows Terminal
Shell: bash

For AI issues: which model did you use?

Composer 2.5 and Composer 2.5 Fast (as recorded in the exported Cursor Usage CSV).

For AI issues: add Request ID with privacy disabled

a7625624-a15b-4d15-be3e-5e3368416227

Additional Information

Background

I was investigating the configuration and execution history of scheduled automations using Cursor Agent.

Because agent automations list had previously hung or failed to return usable results, I explicitly instructed the agent not to use that command and to use read-only Connect RPC calls instead.

Despite those instructions, the agent attempted the command multiple times.

Incident details

  • Date: October 16, 2026
  • Usage spike: 11:41–12:14 JST (02:41–03:14 UTC)
  • Operating environment: Windows 11 / WSL2 (Ubuntu)
  • Cursor CLI installation version directory: 2026.10.14-0f9edde
  • Parent conversation ID: a7625624-a15b-4d15-be3e-5e3368416227

Usage impact

  • Total: approximately 317,661,480 tokens
  • Cache reads: approximately 302,398,653 tokens (95.2%)
  • Usage records: 376
  • Remaining usage allowance: 63% → 40%

Local logs suggest that the CLI may have interpreted automations list as an AI prompt due to an unexpected command-handling issue.

This appears to have initiated a chain of additional agent sessions that repeatedly investigated the same CLI behavior.

I am not claiming that token accounting itself is necessarily incorrect. My concern is that unintended agent execution caused an extremely large amount of usage.

I would appreciate an investigation into the suspected CLI issue, the lack of safeguards against cascading agent execution, and the resulting usage impact.

I have preserved local session logs and the exported usage CSV. I can provide redacted evidence upon request.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey @M_Y, thanks for the report, and sorry about the usage this burned.

You read it right. The agent automations commands aren’t available on your account yet, and when the CLI doesn’t recognize the first word, it treats everything after agent as a prompt. So agent automations list started a new agent whose task was “automations list”. When the CLI runs inside another agent’s terminal it runs headless, and that new agent tried to list your automations the same way, which started another agent, and so on.

I’ve flagged this to the team.

In the meantime, to make sure it can’t repeat:

  1. Manage automations from the Automations page at cursor.com/automations rather than the CLI.
  2. Open ~/.cursor/cli-config.json (inside WSL). If approvalMode is set to "unrestricted", change it to "allowlist". Agents started headless by another agent only run terminal commands without asking when that setting is on, so this stops a chain at the first step.

Could you let me know whether approvalMode was set to "unrestricted" before this happened? That helps confirm how far the chain could reach.

7

@Colin

Hi Colin,

Thank you for the detailed explanation and for flagging this to the team.

I checked my ~/.cursor/cli-config.json and confirmed that approvalMode is currently set to "unrestricted". The sandbox mode is also "disabled".

I haven’t changed these settings since the incident, so I believe they were the same when it occurred.

This seems consistent with your explanation of how the recursive agent execution was able to continue.

I’ll consider changing approvalMode to "allowlist" to prevent this from happening again.

Thanks again for your help!