Add a `--prompt-file <path>` flag (large prompts hit ARG_MAX; stdin is awkward)

[baiwei0427]

Summary

Add a --prompt-file <path> flag to read the prompt from a file instead of from -p <text> or stdin.

Motivation

Today there are two ways to give Copilot CLI a prompt in non-interactive mode:

1. -p "$(cat prompt.md)" — convenient, but the whole prompt is passed on the command line, which is subject to ARG_MAX (~2 MB on typical Linux). For our use case (code-review bot that inlines the PR diff plus prior reviews) this is close enough to the limit to be a concern.
2. < prompt.md (stdin) — works, no size limit, but is awkward to thread through wrapper scripts that already use stdin for other purposes, and it's harder for new users to discover.

A first-class --prompt-file flag would:

• Have no size limit (just reads the file).
• Be self-documenting in scripts (copilot --prompt-file ./review-prompt.md vs copilot -p "$(cat review-prompt.md)").
• Compose naturally with workflows that build prompts incrementally (instructions + diff + prior reviews) into a single file.

Suggested behaviour

copilot --model gpt-5.5 --prompt-file ./prompt.md       # equivalent to `-p "$(cat ./prompt.md)"` but unbounded
copilot --model gpt-5.5 --prompt-file -                  # explicit stdin (same as today's bare `<`)

Mutually exclusive with -p/--prompt. Error if the file doesn't exist or is empty.

Why now

I just shipped a self-hosted GitHub Actions workflow that calls Copilot CLI three times per PR (two reviewers + synthesiser), each with a prompt that inlines the PR diff, repo instructions, and (for the synthesiser) the two prior reviews. The consensus prompt can approach several hundred KB; we use stdin today, which works but isn't obvious to anyone reading the workflow. --prompt-file would make the intent clear without a wrapper.

Environment

• GitHub Copilot CLI: 1.0.49
• Use case: non-interactive -p/stdin in GitHub Actions

[gmickel]

+1 — and a Windows data point that makes this much more urgent than the Linux 2 MB ARG_MAX case.

On Windows, CreateProcessW caps lpCommandLine at 32,767 chars — about 64× smaller than Linux ARG_MAX. Anything that wraps Copilot CLI to do agent-driven code review (we ship flow-next, a spec-driven SDLC plugin) hits this on the very first spec-sized review, with no warning — it surfaces as opaque OSError [WinError 206] The filename or extension is too long.

In flow-next 1.1.8 we just added a fail-fast guard (flowctl.py change) so Windows users get a clean "this can't work, run from WSL" message instead of the cryptic OSError. But that's a workaround for the symptom; we have no way to deliver spec-sized prompts to Copilot CLI on native Windows without --prompt-file (or documented stdin support).

A first-class --prompt-file <path> would let us ship Copilot review backend support on Windows immediately. Stdin works on Linux per @baiwei0427's note above but is awkward through wrapper subprocess code (we'd need to thread stdin through subprocess.run's input= and avoid interleaving), and it's less self-documenting in skill / agent prose where we point users at the underlying CLI.

Use case: AI agents running review CLIs as subprocesses with prompts that bundle spec + diff + prior-review context. Several hundred KB is normal; we routinely exceed Windows' 32 KB cap.

Happy to test a prerelease build the moment --prompt-file lands.

[gmickel]

Update from our side: shipped a workaround in flow-next 1.1.9 (PR #143). Copilot CLI's stdin path (which @baiwei0427's original post mentioned as "works, no size limit, but is awkward") actually works on Windows too — we route subprocess.run(input=prompt, ...) instead of -p "<text>" and the Windows CreateProcessW 32K cap becomes a non-issue. Verified end-to-end via a real-subprocess Windows CI smoke that round-trips a 60 KB prompt and checks the SHA-256.

Two notes from the implementation that might be worth surfacing in --help:

1. Stdin-mode --resume=<uuid> is resume-only. First call needs --session-id=<uuid> (we got Error: No session, task, or name matched <uuid> the first time). -p mode is create-or-resume in a single call. We track first-call state via a touch marker so subsequent calls switch to --resume. Worth documenting that the session semantics differ between argv and stdin modes.

2. Stdin isn't mentioned in --help. Took us reading this issue to discover it. A one-line --help entry ("Prompt may also be supplied via stdin when -p is omitted") would have saved us a release cycle.

Still very much want --prompt-file <path> to land — it removes the asymmetric session semantics, removes the marker tracking, and self-documents in scripts. Happy to test the prerelease whenever.

Thanks for keeping this issue open.