Command failed to spawn: Unexpected token

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Shell Tool Spawn Failure

Date: 2026-02-09
Context: Agent attempted to run create_sprint_branches.sh for Sprint 37 (repo1 and repo2). Manual run in user terminal succeeded.

Problem Summary

The Cursor Shell tool (run_terminal_cmd) failed to spawn every time it was invoked. The failure occurred before any command executed; the error was immediate and consistent across multiple turns and after restarts (Linear, then Cursor).

What Was Attempted

The agent invoked the Shell tool with:

  • Command: cd /Users/chris/dev/repo3 && bash repo3/create_sprint_branches.sh dev-183-sprint-37
  • Optional parameters: required_permissions: ["network"] (for git fetch / git push), plus description and is_background: false.

Error Message

Command failed to spawn: Unexpected token ''', ..."ssions": ['network',"... is not valid JSON

So the failure was in spawning the command (or in handling the tool request), not in the command’s exit code or output.

Likely Cause

The error suggests a JSON parsing error in the request that Cursor sends when invoking the Shell tool. In particular:

  • The fragment ..."ssions": ['network',"... looks like a truncated or malformed required_permissions (or similar) field.
  • Possible causes: bad escaping of quotes in the tool-call payload, a bug in how the agent’s tool call is serialized when required_permissions (or similar) is present, or a bug on the Cursor/IDE side that parses that payload.

What Worked

The user ran the same command manually in their own terminal; the script and branch creation worked. So the failure was specific to the Shell tool integration, not to the command or the script.

Steps to Reproduce

I have a ‘start_sprint.md’ file which is used by an Agent to perform sprint setup operations including branch creation via a script. This script used to work but failed to run for my latest sprint with the error mentioned above.

Expected Behavior

Script should run.

Operating System

MacOS

Version Information

Version: 2.4.31
VSCode Version: 1.105.1
Commit: 3578107fdf149b00059ddad37048220e41681000
Date: 2026-02-08T07:42:24.999Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin x64 24.6.0

For AI issues: which model did you use?

auto

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the detailed report.

This is a known issue. Sometimes the model generates tool call parameters with invalid JSON, like using single quotes instead of double quotes in arrays, for example required_permissions: ['network']. Our parser doesn’t handle this correctly. The team is aware, but we don’t have a fix timeline yet.

As a workaround, you can try:

  • Update to the latest version if you haven’t already (Help > Check for Updates)
  • Pick a specific model instead of “auto”, different models generate tool calls differently
  • Reword the request or restart the chat if it keeps happening, a new session sometimes helps

Also, if you can share the Request ID from the affected chat (top right of the chat > Copy Request ID), that’ll help us track it down.

Let me know if the workaround helps.

4

@deanrie Hi Dean,

I agree the model sometimes emits ['network'] instead of ["network"].

However, I think the deeper issue is that the Shell tool layer appears to rely on strict JSON.parse() without any tolerant parsing or repair step.

Since LLMs do not guarantee strict RFC-compliant JSON (even when prompted), relying on strict parsing makes the tool invocation layer fragile.

A more robust fix could be:

  1. Use a tolerant parser (e.g. JSON5)

  2. Or implement a minimal auto-repair on parse failure

  3. Or validate + coerce arguments against the tool schema before execution

Currently the failure happens before command spawn, which suggests deserialization failure rather than execution failure.

This makes tool reliability dependent on model formatting quirks, which may vary across models or sessions.

Happy to help!

1 Like
5

Thanks for the speedy response, the requestID is e2b246f7-816f-4ff9-b89f-e4900b3d3aa7

I’ll try the workarounds when I start my next sprint (in < 10 days)

1 Like
6

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.