Continue sends duplicate tool-result history for a reused tool-call id

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site to see if the docs have an answer
• I'm not able to find a related conversation on GitHub discussions that reports the same bug
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Linux x86_64 Docker, using `node:24-bookworm`based target image
- Continue version: `@continuedev/cli@1.5.45`
- IDE version: CLI (`cn`), no IDE
- Model: OpenAI Chat-compatible local mock provider, `gpt-4`
- config:
    
    
    name: vendor-repro
    version: 1.0.0
    models:
      - provider: openai
        model: gpt-4
        apiBase: <http://127.0.0.1>:<mock-provider-port>/v1
        apiKey: vendor-repro-fake-key

Description

Severity / performance impact: Medium to High. When the provider reuses tool-call id dup_id_0001 across turns, Continue sends duplicate tool-result entries for that id back to the provider. This can corrupt provider conversation state, trigger provider-side schema errors, or amplify retries.

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 @continuedev/cli@1.5.45 from the public npm package, 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/d4d4d2732a41371dc8a0c219846c22a2

gh gist clone d4d4d2732a41371dc8a0c219846c22a2 continue-duplicate-tool-id-history-pollution-reproducer
cd continue-duplicate-tool-id-history-pollution-reproducer
python3 continue-duplicate-tool-id-history-pollution.reproduce.py

To reuse an already-built local image:

python3 continue-duplicate-tool-id-history-pollution.reproduce.py --skip-build

Log output

Expected successful reproduction output includes:


provider_requests=442
duplicate_tool_result_in_request dup_id_0001: observed=441 expected>=2
REPRODUCED

Start by running the linked self-contained reproducer with the Continue CLI environment described in the issue and inspect the CLI's tool-result history handling. Trace the request construction until the reused tool-call id is serialized, then rerun the reproducer; done means repeated requests no longer contain duplicate tool-result entries for dup_id_0001.