Interrupted terminal tool result can't distinguish “cancelled at approval prompt” vs “cancelled mid-execution”

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Composer / Agent (Terminal tool)

Describe the Bug

When a terminal command launched by the Agent is interrupted, the tool result is:
Shell command was interrupted by the user after <N>ms before it completed.

This identical message is returned in two materially different situations:

  1. The command was blocked at the permission/approval prompt and the user dismissed it — it never executed.
  2. The command had already been approved and was running, and the user stopped it mid-flight — side effects may have already occurred.

The tool result contains no field that distinguishes these cases — there is no “awaiting approval / never started” vs “started executing” signal, and no exit state.

Impact — for an autonomous agent this ambiguity is a correctness/safety hazard:

  • If the agent assumes “didn’t run” when it actually ran, a retry can double-apply a side-effecting action (post a duplicate comment, create a duplicate resource, re-run a migration, etc.).
  • If it assumes “ran” when it didn’t, it may skip a required action.

The agent can partially infer the truth from elapsed-time-vs-expected-runtime (a normally ~1s command sitting idle for 33s was almost certainly blocked on an approval prompt), but that is a heuristic — for normally slow commands the outcome is genuinely undecidable from the tool result.

Suggested fix — include a machine-readable execution-state field in the interrupted tool result, e.g. execution_state: "blocked_awaiting_approval" | "running" | "completed" and/or started: true|false. At minimum, make “cancelled before approval (never executed)” textually distinct from “cancelled after start,” so the agent can decide whether a retry is idempotent-safe or requires verification first.

Steps to Reproduce

  1. Have the Agent run a terminal command gated behind a permission approval (e.g. a network command).
  2. When the approval prompt appears, dismiss/cancel it instead of approving.
  3. Note the tool result: ...interrupted by the user after <N>ms before it completed.
  4. Separately, approve a longer-running command, then stop it mid-run.
  5. Compare the two results — they are indistinguishable; neither indicates whether execution actually started.

Expected Behavior

The tool result should clearly indicate whether the command ever began executing (via a distinct message or a structured field), so the agent can reliably tell “never ran” from “ran and was cancelled” and avoid unsafe retries.

Operating System

MacOS

Version Information

Cursor 3.6.31 (commit 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60), macOS (darwin 25.5.0)

Does this stop you from using Cursor?

No - Cursor works, but with this issue

7

You’re right that the interrupted tool result message doesn’t distinguish between “cancelled at the approval prompt” and “cancelled mid-execution,” and the safety implications you described are real.

We’ve filed this with our agent harness team. No workaround beyond the elapsed-time heuristic you already identified, unfortunately. We appreciate the thorough analysis - it made confirming this straightforward.