Stop hook followups fail to land after waiting for background tasks

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Stop hook followups fail to land after waiting for background tasks.

Steps to Reproduce

  1. When a CLI agent waits for background tasks, a stop hook is fired, and leads to a followup message queued. (Figure 1)
  2. When the background tasks finished and the agent really stopped (idle), the queued message is still in queue (follow-ups) and failed to input as a prompt. (Figure 2)

Expected Behavior

When the agent goes idle, the follow-up message should land as a user prompt.

Operating System

Linux

Version Information

About Cursor CLI

CLI Version 2026.05.16-0338208
Model GPT-5.4 272K Medium
Subscription Tier Enterprise
OS linux (x64)
Terminal vscode
Shell zsh

For AI issues: which model did you use?

Any

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Figure 1:

Screenshot 2026-05-20 at 2.18.22 PM
Screenshot 2026-05-20 at 2.18.22 PM2718×442 35 KB

Figure 2:

Screenshot 2026-05-20 at 2.18.59 PM
Screenshot 2026-05-20 at 2.18.59 PM3486×466 35 KB

In addition, any further followups are blocked. The followup queue seems broken after this behavior.

7

Thanks for the detailed report and screenshots. I attempted to reproduce this on both macOS and Linux with a stop hook that introduces a deliberate delay and returns a followup_message, combined with a short background shell task. Across multiple attempts with varying timing windows (2s–8s hook delays), the followup consistently landed as expected.

A few things that would help narrow this down:

  1. Could you share your stop hook script? Your screenshots show the followup originates from a monitor_script hook. Understanding the hook’s logic (especially any file I/O, transcript reads, or network calls) would help me reproduce the exact timing conditions.

  2. Could you check the Hooks Execution Log? Go to Cursor Settings > Hooks > Execution Log — this shows whether the hook fired, what payload it received, and the response it returned. A screenshot or copy of the log entries around the time of the stuck followup would confirm whether the hook executed correctly on Cursor’s side.

  3. Is this reproducible on every session, or intermittent? If intermittent, roughly how often does it trigger (1 in 3 sessions? 1 in 10?)?

  4. Are there other hooks configured besides the stop hook? If you have afterFileEdit, sessionStart, or other hooks that interact with the same state (edit markers, transcript files), the combination may affect timing.

This would help us pin down the specific conditions that trigger the race.