Headless `agent` CLI exits 1 after successful GPT-5.5 run; stderr cites invalid base model `gpt-5.5`

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When running the headless Cursor CLI (agent) with --model gpt-5.5-medium or gpt-5.5-high on long, real-world coding tasks (~10–18 minutes), the agent completes successfully (opens MRs, emits structured result in the chat session DB), but the CLI process exits with code 1, stdout is empty, and stderr reports:

S: AI Model Not Found Model name is not valid: "gpt-5.5"

Note the error references the base slug gpt-5.5, not the tier slug passed on the command line (gpt-5.5-medium / gpt-5.5-high). Short smoke tests (~15s) with the same flags exit 0 and print the expected stdout sentinel.

This looks like a post-run finalization bug (model name normalization to an invalid slug) rather than invalid model configuration.

Steps to Reproduce

  1. Install Cursor CLI (agent), authenticate with CURSOR_API_KEY.
  2. Use a real multi-file repo worktree (we use Android/iOS app repos; ~900s tier budget).
  3. Run headless agent with a long fix prompt and GPT-5.5 tier:
agent -p --force --approve-mcps --trust \
  --workspace /path/to/repo-worktree \
  --output-format text \
  --model gpt-5.5-medium \
  '<long coding task prompt; agent should open MR and print final line AUTO_TRIAGE_RESULT={...}>'
  1. Wait for run to complete (~15–18 minutes in our cases).

Expected Behavior

A non-zero exit code would be great!

Operating System

MacOS

Version Information

Item Value
OS macOS 25.5.0 (darwin)
Cursor CLI (agent) 2026.05.16-0338208 (/Users/nels/.local/bin/agent)
Invocation Headless: -p --force --approve-mcps --trust --workspace <path> --output-format text --model <tier>
Models affected gpt-5.5-medium, gpt-5.5-high (listed by agent models)
Models OK (control) composer-2.5-fast on same invocation shape

For AI issues: which model did you use?

Appears with GPT models and Clause models

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

This is a confirmed bug in how GPT-5.5 model slugs are validated during certain backend calls. The main agent requests succeed because they use the full parameterized model selection, but a post-run validation call sends the bare base model ID gpt-5.5 which gets rejected. Your diagnosis (post-run finalization bug) is spot on.

Our team is actively working on a fix. In the meantime, composer-2.5-fast (or any non-GPT-5.5 model) will work without the exit code issue, which you’ve already discovered.

I’ll update this thread once the fix ships. Thanks for the detailed repro and version info.

Got it; thank you for the confirmation. I’ll work around the exit code for now and look forward to that fix!

I can reproduce this deterministically in headless CLI when the agent uses a background shell task.

Minimal shape:

```bash

CURSOR_CONFIG_DIR=/tmp/cursor-agent-repro-config \

cursor-agent -p ‘In this disposable directory, run a background shell command that sleeps for 3 seconds and prints repro-ok, wait for it to complete, then reply with exactly: done’ \

–output-format stream-json \

--model gpt-5.5-medium \

-f

This also fails for claude-opus-4-7-medium but not for composer-2.5-fast, and is due to normalization of the model name within the configuration file produced by cursor-agent cli.

Please fix! Thanks

This sounds like Cursor’s core CLI product fails to work properly for 2 of the 3 frontier LLM providers, and it’s been three weeks without a fix. Am I misunderstanding something, or is the whole team on vacation?

A fix for exactly this just merged. It’s currently in the nightly/pre-release builds but hasn’t reached the stable CLI release yet, so a normal update won’t pick it up for another release or so. If you’re comfortable running a pre-release build, you can get it now; otherwise it should land in an upcoming stable release and I’ll update this thread when it does.

Thank you! I’ll give the nightly build a try.