Repository navigation
Add a --prompt-file <path> flag (large prompts hit ARG_MAX; stdin is awkward) #3398
Description
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:
-p "$(cat prompt.md)"— convenient, but the whole prompt is passed on the command line, which is subject toARG_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.< 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.mdvscopilot -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
Activity
gmickel commentedon May 22, 2026
+1 — and a Windows data point that makes this much more urgent than the Linux 2 MB ARG_MAX case.
On Windows,
CreateProcessWcapslpCommandLineat 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 opaqueOSError [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 throughsubprocess.run'sinput=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-filelands.fix(flow-next): Windows+Copilot argv-cap guard — 1.1.8 (#142)
fix(flow-next): Copilot stdin path on Windows — 1.1.9 (#143)
gmickel commentedon May 22, 2026
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 WindowsCreateProcessW32K 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:Stdin-mode
--resume=<uuid>is resume-only. First call needs--session-id=<uuid>(we gotError: No session, task, or name matched <uuid>the first time).-pmode 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.Stdin isn't mentioned in
--help. Took us reading this issue to discover it. A one-line--helpentry ("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.
fix(providers): stop passing prompt bodies in argv (#279)
docs: size is the host's problem, and never a reason to change stage
revert(cli): drop the copilot-on-Windows restriction, to land separat…
revert(cli): drop the copilot-on-Windows restriction, to land separat…