Deterministic `editToolCall` JSON parse failure on `cursor-agent` when Anthropic tool_use is served from Bedrock (Vertex path succeeds identically)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Every edit_file tool call is unparseable (position 125, missing comma between
path and contents) when the Anthropic model instance is served from AWS
Bedrock; identical calls succeed 100 % when routing lands on Google Vertex.

  • Product: Cursor Agent CLI, 2026.05.28-a70ca7c (running under
    --print --output-format stream-json --model claude-opus-4-7).
  • Deployment: headless, non-interactive, one CLI invocation per microservice.
  • Model alias requested: claude-opus-4-7
  • Model as reported by CLI on system init event: Opus 4.7 (Thinking) 1M Extra High
  • Runner OS: RHEL 8 host, container built from bitnami/openjdk:17-debian-12
    (JVM host launches cursor-agent).
  • Network: corporate network with HTTPS_PROXY to api2.cursor.sh; no proxy
    transformation on the tool call payloads (proxy is TLS pass-through).
  • Approx. workload per invocation: 30-45 minute session, 150-250 tool calls,
    including 30-60 edit_file calls with 20-90 KB contents.

Every edit_file tool call in an affected session fails with the same shape:

JSON.parse error: Expected ',' or '}' after property in object at position 125

The byte 125 sits immediately after the path field value in the tool_use
arguments, i.e. the model appears to have emitted:

{"path":"/tmp/.../output/ApiProfile.md""contents": …
                                        ^ missing comma

The CLI retries via its checkpoint mechanism (rewind to last valid state and
re-emit). Because the checkpoint restores the same model state, the same
malformed argument is re-emitted and the retry hits the same parse error at the
same byte position. After several attempts the CLI aborts with
resource_exhausted and the process exits non-zero.

What we can rule out

  • Not content-driven. The identical ApiProfile.md content that fails in
    one session was verified re-writable in a fresh cursor-agent session on a
    different network path.
  • Not path-length-driven. The absolute path (~120-160 chars) writes cleanly
    in isolated reproduction with the same tool schema on newer CLI builds.
  • Not CLI-version-driven. The 2026.05.28 CLI ships work when routing
    lands on Vertex, so the binary itself is capable of parsing valid tool_use.
  • Not model-alias-driven. Same alias (claude-opus-4-7) succeeds in the
    Vertex-routed sessions.
  • Not prompt-driven. Same prompt template, same repo checkout, same
    cursor-agent args between failing and succeeding sessions.

What we CAN correlate — with hard numbers

We enumerated the Anthropic tool_use.id prefix (toolu_bdrk_ vs
toolu_vrtx_) across 6 sessions in the same pipeline for the same
microservice..

100% correlation: toolu_bdrk_ sessions parse-fail every attempt; toolu_vrtx_
sessions parse-clean every attempt. No mixed-prefix session was observed —
routing is stable per invocation.

Steps to Reproduce

  • Reproduction depends on routing choice, which we do not control from the CLI.
    We have not been able to reproduce on a fresh account (routing there landed
    on Vertex).
  • On the affected account, submitting a edit_file with any large contents
    (30+ KB) reliably hits the failure while the account is being routed to
    Bedrock.

Expected Behavior

edit tool call succeeds and not fails on json parse.

Operating System

Linux

Version Information

  • Product: Cursor Agent CLI, 2026.05.28-a70ca7c (running under
    --print --output-format stream-json --model claude-opus-4-7).
  • Deployment: headless, non-interactive, one CLI invocation per microservice.

For AI issues: which model did you use?

  • Model alias requested: claude-opus-4-7
  • Model as reported by CLI on system init event: Opus 4.7 (Thinking) 1M Extra High

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey @dmitry_afk!

Thanks for the report.

Could you collect Request IDs – one when the routing goes to Bedrock (where it fails) and one when the routing goes to Vertex, and share them here?

You can collect these from the JSON response:

{
   "type":"result",
   "subtype":"success",
   "duration_ms":3425,
   "duration_api_ms":3425,
   "is_error":false,
   "result":"Hi! I received your message but \"test\" is a bit ambiguous. What would you like me to help you with?",
   "session_id":"20073db4-dd25-4c4f-b67e-6c4fb818631f",
   "request_id":"5a71cce4-6f36-4b56-841d-e66f35e54d78", <----
   "usage":{
      "inputTokens":6,
      "outputTokens":36,
      "cacheReadTokens":0,
      "cacheWriteTokens":35829
   }
7

We didn’t keep request ids, I’ll will capture those in future.
Below are the details we have (session ids and tool call ids)

(FAILED, Bedrock)
session_id: 91548755-4c55-4cce-ab37-d21dac8e56d9
call_id samples:
toolu_bdrk_015S1Fx3UvZXbPAJfUf6UJy9
toolu_bdrk_01Trzt11A9vWcFiEgyopihHZ
toolu_bdrk_01JgDkShqpC22k3wMC94j15Y
toolu_bdrk_01Vh7xSX1Urtc1zqG1bHAWmH
toolu_bdrk_01KHVJAL4aeXTfWh2SoB9G3Y
toolu_bdrk_01W74QBw1EpypAQ41iKtKMHk
(FAILED, Bedrock)
session_id: 6fac0000-f7fe-414a-9283-470c93330249
call_id samples:
toolu_bdrk_01NmMX9AmcQ46czrgrkkQLtY
toolu_bdrk_0146qL6aktRoDTewLMp9EUHK
toolu_bdrk_01TwieJ3pcMXc6Jf1XHEUzBu
toolu_bdrk_016vWfSN5mCWJXHDczCbKxoy
toolu_bdrk_01SJsJesJV1oKF65hPmJTCLm
toolu_bdrk_012riUgRhAFMjtjayFr1KmHr
(SUCCEEDED, Vertex)
session_id: 2c5e2b00-d6fc-4493-8580-3965fce1c20d
call_id samples:
toolu_vrtx_01Bk4zYpvYJEbrNSJBfdijgc
toolu_vrtx_01DttfMaCbfBnAUjAmMFMp9z
toolu_vrtx_01Vu6KUexzNHycEoEpVs4LFU
toolu_vrtx_014GG3ekrAof6cEG2QigxPND
toolu_vrtx_01MBaZ2G393HrsPH3NMsiouF
toolu_vrtx_01WDwzBQ2oGoV28ffGZNWrxM
(SUCCEEDED, Vertex)
session_id: 4a96271f-9ea6-43f7-b398-4d21203f22fa
call_id samples:
toolu_vrtx_01LD352tJs8vBGuRGfsFxDGx
toolu_vrtx_01GnkbZRUF5chNhZJZ2pcP5P
toolu_vrtx_01P4Lnw8w7P1oxFANkWFVSmQ
toolu_vrtx_01SMRxcrpSPpCVQcpSndGxUS
toolu_vrtx_01RxD9KSLh5DALD3qqSGubMi
toolu_vrtx_01XGaoBB3wGzE6DhL1dhPYw5