-p/--prompt values starting with - incorrectly parsed as flags (regression in 1.0.85)

Start at the CLI argument-parsing entry point and reproduce the issue with the bundled app.js using -p followed by a value beginning with '-'. Compare that behavior with the working --prompt= form; done means both forms accept a single argv value beginning with '-' without the misleading quoting error.

Describe the bug

-p/--prompt values that begin with a - character (e.g. a prompt whose text starts with YAML frontmatter like ---) are misparsed as CLI flags instead of the prompt value. This produces a misleading error telling the user their prompt "was not quoted", even when the prompt was passed correctly as a single argv element (no shell involved).

This is a regression: the same invocation works correctly on 1.0.80 and 1.0.81, and fails starting at 1.0.85.

Affected version

1.0.85

Steps to reproduce the behavior

Reproduced without any shell involvement (Python subprocess.run with an argv list), ruling out shell quoting/word-splitting as the cause:

import subprocess
p = "---\nfoo bar baz"
r = subprocess.run(["copilot", "--allow-all", "-p", p], capture_output=True, text=True)
print(r.returncode, r.stderr)

Output:

error: Invalid command format.

It looks like your prompt was not quoted, so the extra words were treated as separate arguments.
Wrap the prompt in quotes, for example: copilot -p "your prompt here"

Try 'copilot --help' for more information.

Minimal repro also confirmed directly on the command line:

copilot --allow-all -p '---
foo bar baz'
# -> error: Invalid command format. ...

copilot --allow-all -p 'hello world'
# -> works fine

Binary search on a real ~9KB multi-line prompt (a persona file with YAML frontmatter) showed the failure boundary was exactly at the leading -- characters of the --- frontmatter delimiter — i.e., any -p value starting with - triggers it, regardless of length or content afterward.

Expected behavior

-p/--prompt <text> should accept any string value passed as a single argv element, including one that begins with - or --, without misinterpreting it as a flag. This worked correctly through at least 1.0.81.

Workaround

Using the = form avoids the bug entirely:

copilot --allow-all --prompt='---
foo bar baz'
# -> works fine, same content

Additional context

• This broke a real workflow: a Rust CLI tool that shells out to copilot via std::process::Command with .arg("-p").arg(&prompt) (two separate argv elements, not a single string with embedded spaces). The prompt content is a file that begins with YAML frontmatter (---\n...\n---), which is a common and reasonable convention.
• Confirmed via direct testing against the bundled app.js for each version (node app.js --allow-all -p '---\nfoo bar baz'):
  • 1.0.80: succeeds
  • 1.0.81: succeeds
  • 1.0.85: fails with the "was not quoted" error
• Root cause appears to be in the CLI's arg-parsing layer (clap-based) treating any -p/--prompt value starting with - as an unrecognized flag/subcommand, which then trips a heuristic (added to produce a friendlier error message for genuinely unquoted multi-word shell invocations) that misfires here because the value was in fact passed correctly as a single argument — it just happens to start with a dash.

Fix applied on our end

We worked around this by switching our call site from -p <value> (two args) to --prompt=<value> (single arg), which avoids the parser's flag-detection heuristic. Filing this so the underlying regression can be fixed and the workaround isn't required.