Continue can execute a tool effect after SIGINT cancellation

[trackoor]

Continue can execute a tool effect after SIGINT cancellation

Before submitting your bug report

• I checked for duplicate local reproduction drafts.
• I reduced the reproducer to a single deterministic local-provider case.

Relevant environment info

• OS: Linux x86_64 Docker
• Continue version: @continuedev/cli 1.5.46
• IDE version: CLI (cn), no IDE
• Model: OpenAI-compatible local mock provider, gpt-4

Description

Severity / performance impact: High. A cancellation window can still allow a later tool side effect, so user interruption does not reliably stop tool execution.

To reproduce

Prerequisites: Docker, Python 3, and the GitHub CLI (gh) for the clone command below. The linked reproducer is self-contained and uses only Python standard-library modules plus Docker. It builds the affected CLI version from the public package registry, starts a local mock provider, and runs the CLI in an isolated workspace. The Docker run is limited to 2 CPUs and 4 GiB RAM by default.

Complete self-contained reproducer: https://gist.github.com/N0zoM1z0/1af6bb0528ab35da9d89d181de5072d1

The Gist contains continue-late-effect-after-cancel.reproduce.py. Download and run:

gh gist clone 1af6bb0528ab35da9d89d181de5072d1 continue-late-effect-after-cancel-reproducer
cd continue-late-effect-after-cancel-reproducer
python3 continue-late-effect-after-cancel.reproduce.py

To reuse an already-built local image:

python3 continue-late-effect-after-cancel.reproduce.py --skip-build

Expected successful reproduction output includes:

REPRODUCED

Log output

Expected successful reproduction output includes REPRODUCED.

Observed behavior: The reproducer sends SIGINT while the provider stream is delayed, then emits a tool call that writes a marker file. Reproduction succeeds if the marker exists after cancellation.

Expected behavior

Continue should stop consuming late provider tool calls after cancellation and should not execute their side effects.

Public-upstream status

This reproduces against stock public @continuedev/cli@1.5.46 built from npm.

[d3f4w2]

I investigated this against the current main branch and found the cancellation gap in the headless CLI path.

getStreamingResponse() creates an AbortController, but it is not connected to SIGINT. The process-level SIGINT handler starts asynchronous shutdown work, leaving enough time for a delayed provider response to reach tool-call handling before the process exits.

I’m preparing a focused fix that:

• aborts the active headless stream synchronously when SIGINT is received;
• removes the temporary signal listener after the request settles;
• adds deterministic regression coverage for abort and listener cleanup.

I found no assignee or open equivalent fix PR before starting.

AI assistance disclosure: I used an AI coding assistant to help investigate the control flow and prepare the patch; I am reviewing and validating the resulting changes.