Foreground shell commands trigger an automatic extra Agent request after the main turn finishes

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Foreground shell commands are causing Cursor to automatically start another Agent request after the main turn has already finished.

In this session, the Agent used normal foreground Shell calls for tests, lint, build and browser QA. It did not request background execution.

After the Agent produced its final report and the turn ended, Cursor showed “Finished 16 background tasks”, automatically resumed the Agent, ran another git status, and generated a second Task Summary.

I did not send another prompt.

Steps to Reproduce

  1. Start a normal Agent task that runs several finite shell commands such as tests, lint or build.
  2. Let the Agent run those commands as normal foreground Shell calls.
  3. Let the Agent finish the task and produce its final response.
  4. After the main turn ends, Cursor may show “Finished N background tasks”.
  5. Cursor then automatically resumes the Agent to process those shell completion events.
  6. The resumed Agent may run additional commands and produce another response even though the user did not send another prompt.

For my reproduced session, 16 foreground shell completions were dispatched immediately after the original Agent turn ended.

Expected Behavior

A shell command that completes as a normal foreground Agent command should not later be treated as a background task completion that resumes the Agent.

Once the Agent has produced its final response and the turn has ended, Cursor should not start another Agent request unless I send another prompt or the Agent explicitly created a background task that requires a later resume.

Screenshots / Screen Recordings

2026-09-18_13-52.png
2026-09-18_13-52.png489×231 5.89 KB

Operating System

Linux

Version Information

Version: 3.20.21
VS Code Extension API: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 7.0.0-31-generic

For AI issues: which model did you use?

Gemini 3.8 Flash High

For AI issues: add Request ID with privacy disabled

Automatically resumed request:
9457b996-b90c-48bd-a5ec-ac8f130756fa

Original main request:
fdb6a754-e7b7-436e-9178-9f1c8ba44ad8

Additional Information

I checked the local Cursor transcript and request traces for this specific session.

Agent ID:
da680e0b-cad9-4cde-9886-759221928386

The original Agent turn ended successfully, then Cursor dispatched a second request through dispatchBackgroundTaskCompletionAction.

The 16 shell commands involved were recorded as foreground commands. The Agent did not use:

  • run_in_background
  • block_until_ms: 0
  • notify_on_output

The shell completion events had already settled, but were still queued as background wakeups. Once the main turn ended, Cursor dispatched them and automatically resumed the Agent.

I’m on the legacy request-based plan, so automatic additional Agent requests are particularly noticeable.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report and the request IDs. They make it a lot easier to dig in.

Here’s what happened. When the agent runs a terminal command in the foreground, it only waits for a limited time (by default about 30 seconds, unless the agent explicitly sets a longer block_until_ms). Commands that don’t finish within that window keep running, but they get moved to a background terminal and the agent continues. When a backgrounded command finishes, the agent “wakes up” once to check the result. That’s the “Finished 16 background tasks” step and that extra request.

In your session, all 16 commands exceeded the wait window (usually tests, lint, and build), so from the agent’s perspective they became background tasks even though it didn’t ask for that. Some of them also finished the day before, and their notifications sat there until the chat became idle.

Two things help for now:

  1. Add a rule in Cursor Settings → Rules like: “For tests, lint and build commands, set block_until_ms high enough for the command to finish in the foreground (e.g. 300000 for a test run). If a command is moved to the background anyway, use AwaitShell on it until it finishes before moving on.” When the agent waits on a backgrounded command via Await, its output counts as already seen and no wakeup gets queued for it.
  2. If after a turn you see a banner above the input that says “N Terminals” or “Working”, open it and stop anything that’s still running. That prevents late wakeups from those commands.

I agree that a completed command whose output the agent already read (especially from the previous day) shouldn’t start a new turn on its own. I’ve shared this with the team, and I’ll reply in the thread if there’s an update.