-p / --prompt tokenizes value on whitespace, breaking all multi-word non-interactive prompts on v1.0.44-0 (Windows)

[dipakboyed]

Describe the bug

copilot -p "<multi-word prompt>" (and --prompt, --prompt=, -i) exits 1 with error: too many arguments. Expected 0 arguments but got N. whenever the prompt value contains a space. The CLI is tokenizing the prompt argument value on whitespace and treating the extra "words" as positional arguments.

The math is exact: word_count_in_prompt - 1 = "got N". The first word is consumed as the prompt value; every other word is rejected.

This breaks every non-interactive automation that uses anything more than a one-word prompt. It is not cosmetic — exit code is 1, stdout is empty, and on --output-format json no JSON ever gets emitted.

This may be the same root cause as #1484, but that one was filed against 0.0.410, framed as cosmetic ("doesn't seem to affect the work"), and the workaround there (just ignore the trailing line) doesn't apply here — on 1.0.44-0 the CLI never produces output. Filing separately so the regression visibility / severity is clear; close as dup if you prefer.

Affected version

GitHub Copilot CLI 1.0.44-0
(copilot update reports "no update needed, current version is 1.0.44-0, fetched latest release is v1.0.44-0")

Steps to reproduce the behavior

Minimal repro — only model + prompt, nothing else:

PS> copilot -p "hello" --model claude-sonnet-4.5
exit 0  ✅

PS> copilot -p "say hello" --model claude-sonnet-4.5
exit 1  ❌  stderr: error: too many arguments. Expected 0 arguments but got 1.

PS> copilot -p "respond with one word ok" --model claude-sonnet-4.5
exit 1  ❌  stderr: error: too many arguments. Expected 0 arguments but got 4.

PS> copilot --prompt "respond with one word ok" --model claude-sonnet-4.5
exit 1  ❌  stderr: error: too many arguments. Expected 0 arguments but got 4.

PS> copilot --prompt="respond with one word ok" --model claude-sonnet-4.5
exit 1  ❌  stderr: error: too many arguments. Expected 0 arguments but got 4.

PS> copilot -i "respond with one word ok" --model claude-sonnet-4.5
exit 1  ❌  stderr: error: too many arguments. Expected 0 arguments but got 4.

Pattern: 4-word prompt → got 3, 5-word prompt → got 4, 43-word prompt → got 42. The first word becomes the prompt value, all others are treated as positional args.

Same failure with the full set of flags we use (--allow-all --no-ask-user --disable-builtin-mcps --no-custom-instructions --output-format json --disable-mcp-server azure --disable-mcp-server playwright --disable-mcp-server ServiceTree) and with both claude-sonnet-4.5 and claude-opus-4.7-1m-internal.

Expected behavior

Quoted multi-word values for -p / --prompt / -i should be received as a single argument (which they are, at the OS / argv level — verified via Process.ArgumentList and a Python subprocess argv inspector both pass exactly one element). The CLI should not re-tokenize the value internally on whitespace.

copilot -p "respond with one word ok" --model claude-sonnet-4.5
→ exit 0, model responds

Additional context

• OS: Windows 11
• Architecture: x86_64
• Terminal: Windows Terminal
• Shell: PowerShell 7

Workarounds we found (sharing in case useful for triage):

Approach	Result
copilot -p "underscore_separated_prompt" ...	✅ exit 0 (but obviously degrades prompt quality)
"prompt text" | & copilot --model X (PowerShell native pipe)	✅ exit 0
echo prompt text | copilot --model X (cmd.exe pipe)	❌ exit 1, empty stderr/stdout
Python subprocess.Popen(..., stdin=PIPE).communicate(input="prompt text")	❌ exit 1, empty stderr/stdout
.NET ProcessStartInfo with RedirectStandardInput=true + WriteLine	❌ exit 1, empty stderr/stdout

So even the stdin workaround is fragile — only PowerShell's native pipe seems to set up the child's stdin in a way the CLI accepts, and we have not been able to replicate it from any other launcher (cmd.exe, Python, .NET ProcessStartInfo all silently exit 1 with empty output).

The combination of (a) -p being broken for multi-word prompts and (b) every alternative invocation path other than PowerShell native pipe also failing means there is currently no reliable way to invoke copilot non-interactively from a daemon / CI / programmatic launcher on Windows. We hit ~30 review failures in a row in our internal PR review tool today before tracking this down.

Happy to share full repro logs, our exact failing argv, or run additional diagnostics if it would help.

[dipakboyed]

Self-correction — closing this issue as invalid

This issue's premise (-p / --prompt tokenizing on whitespace) is wrong. The "got N arguments" error I reported was actually caused by a bug in my reproduction harness: PowerShell Start-Process -ArgumentList @("--prompt", "respond with one word ok") strips the surrounding quotes and re-splits array elements on whitespace before launching the child process, so copilot never received "respond with one word ok" as a single argument — it received seven separate args.

Direct invocation works correctly:

copilot --prompt "respond with one word ok"   # exit 0, works as expected

The actual bug I was hitting in my daemon is now filed correctly as #3188 — copilot exits 1 with empty streams when invoked from subprocess.Popen (or any non-PowerShell launcher) on Windows because of a FlushFileBuffers failure on stdout. Closing this one to consolidate the conversation there.

Apologies for the noise.