CLI: positional prompt arg scanned for embedded short-option letters (-p/-P) → SIGKILL; -- ignored

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When the prompt is passed as a single positional argv element (spawned via execve, no shell),
cursor-agent scans inside that token and treats an embedded -p / -P substring as the
--print short option — even though the token does not start with -. The phantom --print
then conflicts with --output-format stream-json and the process is killed: exit 137 (SIGKILL),
zero bytes of output. The POSIX -- end-of-options separator does NOT prevent it.
This bites in practice because ordinary text — a branch/env name like ...-PROD-... (-P) or
...-patch-... (-p) — silently kills the process with no error message.

Steps to Reproduce

CRASHES: exit 137, 0 bytes (embedded -p)

cursor-agent --output-format stream-json --trust --approve-mcps “Reply hi only. ref alpha-print-x”

CRASHES: exit 137, 0 bytes (embedded -P, case-insensitive; e.g. a “PROD” token)

cursor-agent --output-format stream-json --trust --approve-mcps “Reply hi only. ref release-PROD-9”

STILL CRASHES: the -- end-of-options separator is ignored

cursor-agent --output-format stream-json --trust --approve-mcps – “Reply hi only. ref alpha-print-x”

WORKS: exit 0, normal output (any other letter than p/P)

cursor-agent --output-format stream-json --trust --approve-mcps “Reply hi only. ref alpha-QUEBEC-x”
Discriminator: I swept every embedded dash-letter -a … -z (plus uppercase spot checks).
Only -p / -P crashes; all other 25 letters exit 0. This confirms the prompt substring is being
matched against the option table, and that the crashing option is specifically --print.

Expected Behavior

A positional prompt is opaque text; embedded -x substrings must never be parsed as options,
especially after a -- separator.

Actual

Embedded -p/-P inside the positional prompt is parsed as --print, conflicts with
–output-format stream-json, and the process is SIGKILLed (exit 137) with zero output.

Operating System

MacOS

Version Information

2026.07.08-0c04a8a

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hi @Bingnan_Zhang,
Thanks for the detailed report, but this isn’t a parser bug.

I ran your exact four commands on a current build (headless, non-TTY): all four exited with 0 and produced normal output — both the -p/-P cases and the -- one — with the prompt preserved verbatim. It’s never scanned for embedded options.

What you’re hitting is a startup stall: in headless mode, the CLI can emit nothing for ~20-30s. Exit 137 is your caller’s timeout SIGKILLing it during that silent window - hence “0 bytes + 137.” The -p/-P link is a coincidence (every letter took the same ~20s to the first byte in my runs). It’s a known headless-CLI stall we’re tracking.

To unblock:

  1. Raise your caller’s timeout to 60s+ - that alone should stop the exit 137s.
  2. If it still stalls, run once with --debug, share the request ID, and let me know if you’re on a VPN or corporate proxy.

Same issue discussed here: Cursor-agent -p hangs with zero output.

7

Hi @mohitjain ,
Thanks for looking!

The CLI’s own error message proves the parser is reading an embedded -P/-p from the positional prompt as --print. Two controlled pairs, plain terminal, differing by one letter in the prompt:

# --trust requires --print:

cursor-agent --trust “… release-PROD-9” → zsh: killed (SIGKILL)

cursor-agent --trust “… release-TROD-9” → Error: --trust can only be used with --print

# --output-format requires --print:

cursor agent --output-format stream-json --force “… release-PROD-9” → zsh: killed

cursor agent --output-format stream-json --force “… release-QROD-9” → Error: --output-format can only be used with --print

With PROD (has -P), the --print-requirement of --trust/--output-format is silently satisfied — i.e. the CLI thinks --print is set. With TROD/QROD (no p), the exact same command errors out demanding --print. The only thing that changed is a P inside the positional prompt text.

So: an embedded -p/-P in the prompt is parsed as the --print flag; combined with --force/--trust it then hits your known --print + --force/--trust → SIGKILL 137 path. It’s instant (~10ms), no network call, no timeout involved — the error message flips deterministically on the letter p. so i think this is an argv-scanning bug, not the headless startup stall.

8

Fair pushback, and thanks for the controlled pairs. You caught a real gap: my first check ran non-interactively, which auto-enables --print and hides the exact --print-requirement error you’re testing. So I re-ran it properly under a real terminal, on your build era and the current one.

With the prompt as a single quoted token, embedded -p/-P still isn’t parsed: "...release-PROD-9" and "...release-TROD-9" both error the same way asking for --print, and the prompt is preserved verbatim. You’re right that -p maps to --print — but only when a token actually starts with -. Commander reads -pROD-9 as -p plus junk, yet it never scans inside release-PROD-9. (Also, only lowercase -p is a flag; -P isn’t an option at all.)

Since you spawn via execve, the fastest way to settle this: can you paste the exact argv array (one element per line) for a crashing vs a working case? That’ll show whether a --leading token is slipping in.

Two more:

  1. You’re on 2026.07.08 — please try the latest (2026.07.12+) and let me know if it still reproduces.
  2. If it does, run it once with --debug and share the request ID.

One aside on the exit 137: --print together with --trust can sit ~20-30s before the first byte, so a short caller timeout turns into the SIGKILL you saw. Bumping it to 60s+ helps regardless of the above.

9

Thanks — point by point.

1) Exact argv (real spawn: subprocess list, no shell), captured just now on 2026.07.09-a3815c0. The prompt is a single positional element and never starts with -. Only one letter inside the prompt differs between the two runs.

CRASH:

cursor-agent

--output-format

stream-json

--force

Reply hi only. ref release-PROD-9

→ exit -9 (SIGKILL), 27 ms, 0 bytes on stdout/stderr.

WORKING (just P → Q in the prompt, nothing else changed):

cursor-agent

--output-format

stream-json

--force

Reply hi only. ref release-QROD-9

→ exit 0, ~32 s, 851 bytes out.

So there’s no leading-dash token in argv, yet it’s a deterministic SIGKILL that flips on a single letter inside the positional prompt. The timing also rules out a caller-side timeout: the crash is the fast path (27 ms) while the success is the slow one (32 s), and we impose no 20–30 s kill.

2) Upgrading to 2026.07.12+ isn’t possible on our end. That build isn’t on the public channel. The official curl https://cursor.com/install script currently pins 2026.07.09-a3815c0, and cursor-agent update reports “Already up to date” at that same version — 07.09 is the newest we can install. If you have an internal 07.12 build, please share the exact version string and we’ll test it.

3) --debug can’t collect anything in this case. The crash is instant (~27 ms, SIGKILL, zero bytes), so the debug session / local port never comes up and there’s no request ID to share.