非互動自動化：copilot -p 與腳本化執行

不開對話視窗、丟一句指令讓它自己跑完、把結果吐出來就退出——這是把 GitHub Copilot CLI 從「聊天夥伴」變成「自動化工人」的關鍵一招。

前面幾章你都是跟 Copilot CLI「面對面」互動：你打字、它回話，動手前還會停下來問你「這個可以做嗎？」。這一章要教你另一種完全不同的用法。

想像一下：平常的互動模式像是把一位工程師請到你旁邊坐下，你一句他一句，過程中他還會回頭確認「這個檔案可以改嗎？」。這一章要教的非互動模式，則像是寫一張工作紙條、塞進一台會自己動的機器，按下開始，它就照紙條一路做到底，做完把成果丟給你，中間完全不用你在場。

為什麼需要這種用法？因為很多場景根本沒有人坐在電腦前面：半夜排程整理一批檔案、CI 流程裡自動幫你審一次程式碼、把網路抓來的資料丟給它整理成表格再存檔——這些場景沒有人能按 [Y/n]，就是非互動模式的舞台。

有一件事要先說清楚：跟 Codex CLI 不一樣，GitHub Copilot CLI 沒有另外一個獨立的 exec 子指令。它用的是同一個 copilot 指令，加上 -p（或完整寫法 --prompt）這個旗標，直接切換成非互動模式。記一句口訣就好：有人看著螢幕、想跟它聊 → 直接打 copilot；沒人看著、要塞進腳本或 CI → copilot -p "..."。

本章只談終端機裡的 copilot -p這件事本身；把它接進 GitHub Actions、跟團隊協作的完整生產線，留到下一章專章講。

10.1 核心概念：-p / --prompt，跑完就退出

最簡單的形式，就是 copilot -p 後面接一句你的需求，用引號包起來：

copilot -p "Explain this file: ./complex.ts"

官方對這個旗標的逐字說明是：

"Execute a prompt in non-interactive mode. The CLI runs the prompt and exits when done."

翻成白話：在非互動模式下執行一句 prompt，CLI 跑完這句就退出。 全程不會開啟你平常看到的那個對話介面，也不會停下來等你按鍵確認。

(料源：official，GitHub Copilot CLI programmatic reference，查核日 2026-07-18)

還有一個小細節值得記住：官方的旗標說明也補了一句——「非互動執行完之後，結尾的摘要會附一句 copilot --resume=SESSION-ID 的提示，方便你之後接續這次對話」（詳見本章 10.8 節）。也就是說，-p 跑完不是「船過水無痕」，這次對話其實有被存下來，只是不像互動模式那樣一直開著讓你聊。

stdin 與管道：一次只能選一種餵法，別以為可以疊加

copilot 也支援直接把資料用管道（|）灌進去，不加 -p：

echo "Explain this file: ./complex.ts" | copilot

這裡有一個很容易讓人誤會、務必弄懂的規則，官方原文：

"Piped input is ignored if you also provide a prompt with the -p or --prompt option."

翻成白話：只要你同時用 -p／--prompt 給了一句 prompt，管道灌進來的 stdin 內容就會被整段忽略，不會自動併進 prompt 裡一起送出去。也就是說下面這行指令，context.txt 的內容根本不會被讀到：

# context.txt 的內容會被靜靜忽略，不會出現在這次對話裡
cat context.txt | copilot -p "do X"

(料源：official，同上出處，查核日 2026-07-18)

10.2 -s：安靜模式，接進管線就靠它

預設情況下，非互動模式跑完會多印一些「裝飾」——例如目前用了哪個模型、用量統計。如果你要把輸出接給下一個指令（jq、寫進檔案、貼進資料庫），這些裝飾反而是雜訊。這時候加上 -s：

copilot -p "summarize this repository" -s

官方逐字說明：

"Suppress stats and decoration, outputting only the agent's response. Ideal for piping output in scripts."

(料源：official，同上出處)

也就是只留下 agent 的純回答，其他都關掉，非常適合寫進腳本。有一個附帶效果值得記：非安靜模式下，回應輸出會秀出目前用的是哪個模型；一旦加了 -s，這行模型名稱也會被拿掉。

10.3 自動化必用的放行旗標家族

互動模式下，Copilot CLI 動手前常常會停下來問你「要不要執行這個指令？」。但排程、CI、無人值守的場景裡，沒有人能回答這個問題——你必須提前用旗標把「要不要問」講清楚，而不是靠現場有人按鍵。

先看官方逐字定義的一整組放行旗標：

(料源：official，GitHub Copilot CLI programmatic reference ＋ GitHub Copilot CLI command reference，--deny-url 一項只出現在完整指令參考頁，programmatic reference 那頁沒有收錄，查核日 2026-07-18)

Deny 永遠贏過 Allow，這是一條硬性原則，官方逐字：

"Deny rules always take precedence over allow rules, even when --allow-all is set or a matching approval has been saved in permissions-config.json."

也就是說，就算你開了 --allow-all，只要某條規則被 --deny-tool 明確擋掉，那條規則照樣被擋——deny 是最後一道防線，不會被任何 allow 蓋過去。

更細的准駁：--allow-tool 的語法

--allow-tool 不是只能整批放行，還能指定更細的範圍。可以指定的工具種類：

其中 shell、write、url、MCP server 這幾種還能再加上括號裡的過濾條件，把範圍縮到更精確：

# 允許所有 git 子指令（git push、git status……）
--allow-tool='shell(git:*)'

# 只允許精確這一句
--allow-tool='shell(npm test)'

# 只允許寫入這個特定路徑
--allow-tool='write(.github/copilot-instructions.md)'

# 允許寫入任何路徑結尾是 /README.md 的檔案
--allow-tool='write(README.md)'

# 只允許存取 github.com 這個網域
--allow-tool='url(github.com)'

# 允許任何 GitHub 子網域（例如 api.github.com）
--allow-tool='url(https://*.github.com)'

# 只允許 github 這個 MCP server 裡的 create_issue 工具
--allow-tool='github(create_issue)'

(料源：official，同上出處)

官方也提醒了萬用字元的適用範圍，逐字：

"Wildcards are only supported for shell to match all subcommands of a specified tool, and for url at the start of the host name to match any subdomain, or at the end of a path to match any path suffix."

也就是萬用字元只在這兩種情境有效：shell 用來比對所有子指令、url 用在網域開頭比對任何子網域，或路徑結尾比對任何後綴——不要以為到處都能亂丟 *。

官方紅線：這些旗標只能在隔離環境用

官方對 --allow-all 家族的安全警語寫得非常直白，務必逐字轉述：

"It is strongly recommended that you only use these options in an isolated environment. You should never use an alias to apply one of these options every time you start Copilot CLI, as doing so would allow Copilot to use any tool without your explicit permission every time you use the CLI, which could lead to unintended consequences."

翻成白話：強烈建議只在隔離環境使用這些旗標。絕對不要把它們寫成 alias、每次啟動都套用——那等於每次用 Copilot CLI 都讓它未經你明確許可就能用任何工具，很可能造成非預期的後果。

10.4 選模型：--model、優先序、與省錢心法

Copilot CLI 最大的賣點之一，就是可以跨供應商切換模型——不像 Codex CLI 只吃 OpenAI 家的模型、Claude Code 只吃 Anthropic 家的模型，copilot 同一個指令可以指定 GPT 系列、Claude 系列，甚至更多。非互動模式下，用 --model 指定：

copilot -p "What does this project do?" -s --model claude-haiku-4.5

官方建議的選模型心法很直覺：簡單任務（解釋程式碼、產摘要）選快、便宜的模型；複雜任務（除錯、重構）選更強的模型：

copilot -p "Fix the race condition in the worker pool" \
  --model gpt-5.3-codex \
  --allow-tool='write, shell'

官方逐字：「For more complex tasks that require deeper reasoning—such as debugging or refactoring code—you might choose a more powerful model」。

(料源：official，GitHub Copilot CLI programmatic reference，查核日 2026-07-18)

模型怎麼決定：五層優先序

如果你在好幾個地方都設定了模型（環境變數、設定檔、命令列旗標……），Copilot CLI 到底聽誰的？官方明確給出優先序，由高到低：

1. 若使用 custom agent，且該 agent 定義裡有指定 model → 聽它的
2. --model 命令列旗標
3. COPILOT_MODEL 環境變數
4. 設定檔 ~/.copilot/settings.json（或 $COPILOT_HOME/settings.json）裡的 model 欄位
5. CLI 的預設模型

(料源：official，同上出處)

想讓某個模型跨 shell session 持久生效，直接改設定檔（或用互動模式的 /model 指令，選完會自動幫你寫進這個檔案）：

{
  "model": "gpt-5.3-codex",
  "effortLevel": "low"
}

effortLevel（推理力度）是部分模型才支援的額外選項，控制模型在回答前花多少時間「想」。

10.5 官方 CI 範例：把旗標兜起來實戰

把前面幾節的旗標組合起來。官方範例的 write, shell 是功能示意，不是細粒度授權：它會放行所有寫入與所有 shell 指令。新手先從隔離測試 repo、確切路徑與單一測試命令開始：

copilot -p "只修正 src/worker.ts 的 race condition，跑 npm test；不要 commit、push 或連網" \
  --model gpt-5.3-codex \
  --allow-tool='write(src/worker.ts), shell(npm test)' \
  --deny-tool='shell(git push)'

第二個：委派給指定的 custom agent（見第 12 章）做程式碼審查：

copilot -p "只讀取最新 commit 並提出審查建議；不要修改檔案" \
  --allow-tool='shell(git show)' \
  --agent code-review

(料源：official，同上出處)

第二個範例用了 --agent 這個旗標，指定用哪一個 custom agent 執行這次任務——這需要你已經事先建立好一個叫 code-review 的 custom agent 才能用，custom agent 怎麼寫、怎麼建，本書留到第 12 章專章講。

10.6 憑證與機密：延續第 3 章，多一個 --secret-env-vars

CI／排程環境的登入方式，第 3 章已經講過三個環境變數的優先序：

COPILOT_GITHUB_TOKEN  >  GH_TOKEN  >  GITHUB_TOKEN

這裡補一個第 3 章沒提到、跟「腳本化執行」直接相關的細節：官方明講 GITHUB_TOKEN 與 COPILOT_GITHUB_TOKEN 這兩個環境變數的值，輸出時預設就會自動遮蔽（redacted），不需要你額外設定。

如果你的腳本還牽涉到其他敏感的環境變數（例如某個第三方 API 金鑰），想讓它們在輸出裡也被遮蔽，用 --secret-env-vars：

copilot -p "call the internal API and summarize the response" \
  --secret-env-vars='DB_PASSWORD,INTERNAL_API_KEY'

官方逐字：「An environment variable whose value you want redacted in output... Essential for preventing secrets being exposed in logs.」

(料源：official，GitHub Copilot CLI command reference，查核日 2026-07-18)

10.7 存檔與稽核：--share / --share-gist

非互動任務跑完，畫面上的東西通常轉眼就沒了——如果你需要留一份紀錄供事後稽核，或想把結果分享給團隊，用這兩個旗標：

# 存成本機 Markdown 檔（預設路徑 ./copilot-session-<ID>.md）
copilot -p "audit the auth module for security issues" --share=./audit-report.md

# 發布成 GitHub 上的 secret gist（非公開，但仍是雲端存放）
copilot -p "audit the auth module for security issues" --share-gist

官方對兩者都附了同一句提醒，務必轉述：「session transcripts may contain sensitive information」——這份存檔／gist 裡可能夾帶敏感資訊，跟其他 CLI 的 session 紀錄檔一樣，別隨便外流。

(料源：official，同上出處)

10.8 讓下一次接著上一次：--resume、--continue、背景任務等多久

10.1 節提過一個容易被忽略的細節：-p 跑完，退出摘要會附一句 copilot --resume=SESSION-ID 的提示。這代表非互動執行預設就會被存成一個可以接續的 session，不是船過水無痕。

想接續某一次的對話脈絡，用 --resume：

copilot -p "now implement the fix you proposed" --resume=<SESSION-ID>

如果你懶得記 session ID，也可以用 --continue，官方逐字：「Resume the most recent session in the current working directory, falling back to the globally most recent session.」——也就是優先接續當前工作目錄最近一次的 session，找不到才退回全域最近一次。這兩個旗標互斥，不能同時用。

(料源：official，GitHub Copilot CLI command reference，查核日 2026-07-18)

如果你的任務裡有背景 agent 或背景 shell 指令還沒跑完，-p 會等它們一起結束才退出——等多久由這個環境變數控制：

(料源：official，GitHub Copilot CLI command reference，查核日 2026-07-18)

10.9 排程：內建 /every／/after（僅限實驗模式）與外部 cron / Task Scheduler

自動化除了「跑一次就完事」，也常常需要「定期重跑」或「等一段時間後跑一次」。Copilot CLI 有兩層做法。

互動 session 內建：/every 與 /after

在互動模式的對話框裡，可以用這兩個 slash 指令排程：

/every 1h run tests
/after 30m remind me the time

/every INTERVAL PROMPT 是定期重跑，/after DELAY PROMPT 是延遲後跑一次。不帶任何參數、單獨輸入 /every 或 /after，會顯示排程管理面板。

(料源：official，GitHub Copilot CLI command reference，查核日 2026-07-18)

外部排程器：cron / Task Scheduler（更適合正式自動化）

官方明確指出，正式的排程自動化建議交給作業系統內建的排程工具，直接呼叫 copilot -p "你的 prompt" 即可：

# macOS / Linux：crontab 範例，每天凌晨 2 點跑一次
0 2 * * * cd /path/to/project && copilot -p "summarize yesterday's commits" -s --allow-tool='read' >> /var/log/copilot-daily.log 2>&1

Windows 則用工作排程器（Task Scheduler），設定觸發條件後直接指向 copilot.exe -p "..." 即可，做法與其他命令列工具在 Task Scheduler 裡的設定方式一致。

(料源：official，Schedule prompts for GitHub Copilot CLI，查核日 2026-07-18；crontab 範例本身為依官方指引推導的示範寫法，非官方逐字複製)

10.10 結構化輸出：--output-format=json 確實存在，但跟 Codex 的差距在哪

如果你讀過 Codex CLI 的對照章節，可能會有個印象：「Copilot CLI 沒有結構化輸出這回事」。這句話不完全準確，需要拆開講清楚。

Copilot CLI 官方完整指令參考頁裡，確實記載了一個旗標：

copilot -p "list the top 5 files by risk" --output-format=json

官方逐字：「FORMAT can be text（default）or json（outputs JSONL: one JSON object per line）。」

(料源：official，GitHub Copilot CLI command reference，查核日 2026-07-18——這個旗標只出現在完整指令參考頁，programmatic reference 那份聚焦「常用旗標」的精簡頁面沒有收錄它，如果你只讀過後者，很容易誤以為這個功能不存在)

所以誠實的結論是：「一行一個 JSON 物件」的 JSONL 輸出，Copilot CLI 是有的，跟 Codex CLI 的 codex exec --json 概念上同一個等級。但拿 Codex CLI 那一整套結構化輸出工具箱逐項比對，缺口依然存在：

10.11 誠實缺口清單：收尾前，把查無佐證的部分講清楚

自動化腳本最怕的就是「以為官方有寫、其實是自己腦補」。收尾前，把這幾個查證後確定沒找到官方逐字佐證的地方老實列出來，別自己腦補：

• 完整的退出碼（exit code）對照表：查證範圍內沒有找到官方列出「0/1/2……各代表什麼」的完整表。腳本裡判斷成敗，保守做法是「退出碼 + 產出物是否存在」雙重判斷，別只信單一數字。
• --output-schema 這類強制最終訊息符合精確 JSON Schema 的機制：如 10.10 節所述，查證範圍內沒有找到 Copilot CLI 有對應功能。
• non-TTY 環境下 stdin 沒關好導致卡死的已知雷：Codex CLI 那邊有社群回報過具體的 GitHub issue，但 Copilot CLI 這邊查證範圍內沒有找到對應的已知案例——這不代表這個工具完全不會有類似問題（沒有主動關閉 stdin 的父行程理論上仍可能造成類似狀況），只是目前沒有查到 Copilot CLI 專屬、有具體 issue 編號佐證的回報。保險做法一樣適用：排程／CI 環境如果這次不需要用管道餵東西，明講把 stdin 接到空裝置，只是這裡沒有官方或社群的具體案例可以引用佐證這個雷確實發生過。

copilot -p "do the task" -s < /dev/null

本章小結

這一章你學會了把 GitHub Copilot CLI 從「對話夥伴」變成「自動化工人」：

• 核心心法：沒有獨立的 exec 子指令，就是同一個 copilot 加 -p／--prompt；-s 讓輸出乾淨到只剩純文字，適合接管線；stdin 與 -p 只能二選一，不會自動合併。
• 放行旗標家族：--allow-all（--yolo）／--allow-tool／--deny-tool（deny 永遠贏）／--allow-url／--deny-url／--no-ask-user／--add-dir，官方紅線是只能在隔離環境用，絕對不要寫成 alias。
• 模型選擇：--model 搭配五層優先序（custom agent > --model > COPILOT_MODEL > 設定檔 > 預設值），簡單任務配便宜模型、複雜任務配強模型。
• 憑證與機密：延續第 3 章的三層 token 環境變數，多學了 --secret-env-vars 這個輸出遮蔽機制。
• 存檔與接續：--share／--share-gist 留稽核紀錄；--resume／--continue 讓下一次接著上一次；COPILOT_TASK_WAIT_TIMEOUT_SECONDS 控制等背景任務的耐心。
• 排程：互動內建的 /every／/after 目前僅限實驗模式，正式自動化建議交給 cron／Task Scheduler 這種外部排程器。
• 結構化輸出的真相：--output-format=json 確實存在，能吐 JSONL，但沒有 Codex CLI 那種強制符合精確 Schema 的機制，也沒有官方逐字的退出碼對照表——這個落差要親自實測確認，不要假設兩邊功能對等。

下一章我們會把 copilot -p 接進更大的場景——GitHub Actions 裡，看看身為 GitHub 自家產品的 Copilot CLI，在 CI/CD 這條路上有哪些其他工具比不上的天生優勢。

動手試試

1. 跑 copilot -p "summarize the repository structure" -s，感受一下「只留純文字回答」跟平常互動模式的差別。
2. 試試看 echo "hello" | copilot -p "ignore me"，觀察 stdin 是不是真的被忽略了——再試一次不加 -p、只用 echo "..." | copilot，比較兩種寫法的差異。
3. 挑一個你熟悉的小任務，寫一行帶 --allow-tool 精確語法的指令（例如只允許 shell(git status)），實際跑跑看權限是不是真的被限制住了。
4. 跑一次 copilot -p "list top 3 files" --output-format=json，親眼看看每一行 JSON 物件長什麼樣、有哪些欄位——比對本章 10.10 節的表格，確認你這一版的實際行為。
5. （進階）在互動模式打 /experimental on，再試試 /after 30m remind me the time，感受一下這個排程功能目前的實驗性質。
6. （進階）跑 copilot -p "do something"; echo $?（PowerShell 用 echo $LASTEXITCODE），親自確認你這一版的退出碼行為，別直接相信任何教學文章講的數字。

本章官方文件參考

• GitHub Copilot CLI programmatic reference
• GitHub Copilot CLI command reference
• Schedule prompts for GitHub Copilot CLI
• github/copilot-cli Releases（版本號真相與更新頻率）