Hub GitHub Copilot CLI 完整教學

第 16 章

疑難排解與常見錯誤

Copilot CLI 卡住、連不上、被擋、帳單看不懂——這一章是你的自救手冊,教你先分清楚問題出在哪一層,再對症下藥,而不是一路亂猜瞎試。

前面十五章教你怎麼把 GitHub Copilot CLI 用得順手;這一章反過來,處理它「不順手」的時候。想像你家裡請了一位很能幹的助理,大多數時候合作愉快,但偶爾會卡關:可能是你根本認錯人(找到的是他退休的前輩)、可能是他忘了帶識別證進不了門、可能是公司規定他這個月不能加班、也可能是辦公室網路被鎖住他傳不出訊息。這一章就是一張「先查哪裡、再查哪裡」的排錯地圖,照順序走一遍,通常都能找到真正的病灶。

角色定位比照本站 Codex CLI 單元第 16 章的「診斷三件套」與 Gemini CLI 單元第 16 章的「疑難排解與遷移判斷」,但內容完全針對 GitHub Copilot CLI 重新查證——不是把其他單元的文字改個名字交差。

版本時效提醒

本章對照版本為 GitHub Copilot CLI v1.0.71(2026-07-16 釋出),查核日 2026-07-18。這個 repo 光是查證這本書期間就在兩天內連發四個版號,改版速度非常快。本章所有逐字錯誤訊息、旗標、環境變數,最終都要以你電腦上實機跑出來的 copilot --helpcopilot version、官方文件當下的內容為準,書上寫的只是某個時間點的快照。

16.1 第一步,先確認你裝的到底是哪一個

在查任何具體錯誤之前,有一個更根本的問題必須先排除:你裝的、你正在照著操作的教學,講的是不是同一個東西?

GitHub 把「Copilot CLI」這個名字用過兩次,這是全書第 0 章就講過的核心陷阱,這裡在疑難排解的脈絡下再提醒一次,因為它是新手卡關時最容易忽略的第一個可能性:

面向舊:gh copilot(已退役)新:copilot(本書主角)
怎麼裝gh extension install github/gh-copilotnpm install -g @github/copilot(或 brew/winget/安裝腳本)
指令長相gh copilot suggest "..."gh copilot explain "..."copilot(互動)/ copilot -p "..."(非互動)
能做什麼只建議、只解釋指令,唯讀諮詢,不會真的動手完整 agent:讀寫檔案、跑指令、開 PR、接 MCP、自訂代理、hooks
現況2025-10-25 起停止運作2026-02-25 正式 GA,持續更新中

小技巧

網路上還找得到不少教 gh copilot suggest 的舊文章,甚至舊版擴充功能一度還掛在 GitHub CLI 的擴充商店裡。判斷你手上的教學或指令是不是「舊的那個」,記三個線索就好:指令開頭是不是 gh(舊版一定掛在 gh 底下)、文章發布時間(2025-10-25 之後才寫的通常沒問題)、有沒有提到 trust folder(信任目錄)、agentic、MCP 這幾個關鍵字(這些是新版才有的概念,舊版完全沒有)。三條線索只要對得上舊版特徵,就代表你正在看一份過時、對不上現在指令的資料。

如果照著本章後面的步驟排查,發現你的指令、旗標、行為統統對不上——先回頭確認一次你裝的、你查到的資料,講的到底是不是 @github/copilot 這個獨立套件。這個誤會排除掉,很多「查了半天查不到」的困惑會直接消失。

16.2 安裝與版本自查

懷疑是安裝本身出問題時,先用這兩個指令自我檢查:

copilot version    # 確認目前裝的版本號
copilot update     # 更新到最新版

官方提供四種安裝管道,各自的平台限制不太一樣,裝不起來時先確認自己走的是對的那一條:

安裝方式指令平台備註
npmnpm install -g @github/copilot全平台Node.js 22 以上,版本太舊裝了也跑不動
Homebrewbrew install --cask copilot-climacOS/Linux支援自動更新
WinGetwinget install GitHub.CopilotWindows支援自動更新,Windows 少見的原生安裝路徑
安裝腳本curl -fsSL https://gh.io/copilot-install | bashmacOS/Linux支援自動更新

另外也可以直接到 github.com/github/copilot-cli/releases/ 下載執行檔手動安裝,但這條路要自己手動更新版本。順帶一提,GitHub Codespaces 的預設映像已經內建 Copilot CLI,不用額外再裝一次。

重要提醒:套件名字不是 @github/copilot-cli

npm 套件正確名稱是 @github/copilot,不是很多人直覺會打的 @github/copilot-cli。裝了半天 npm install -g @github/copilot-cli 一直失敗,先檢查是不是套件名字本身就打錯了。

Node.js 版本太舊是新手最常在這一步卡住的地方——npm install -g @github/copilot 執行沒有明顯報錯,但裝完的 copilot 指令怪怪的或根本跑不起來,先用 node --version 確認自己的 Node.js 是 22 以上,這是官方寫死的最低需求。

16.3 登入卡住:官方列出的 6 類認證錯誤

登入相關的疑難排解,第 3 章已經講過完整的首次啟動流程;這裡把官方文件逐條列出的錯誤訊息與對應解法整理成一張查表,卡住時直接對照畫面上的錯誤字句:

#錯誤訊息/情境解法
1「No authentication information found」(找不到任何認證資訊)執行 copilot logingh auth login
2「Your GitHub token may be invalid, expired, or lacking the required permissions」(token 可能無效、過期,或權限不足)重新驗證、檢查 token 權限,確認「Copilot Requests」這項權限已啟用
3ghp_ 開頭的舊式 token 被靜默忽略改用細粒度個人存取權杖(fine-grained PAT)
4「Access denied by policy settings」(存取被政策設定拒絕)確認帳戶有有效的 Copilot 授權,或請組織管理員啟用對應政策
5「System keychain unavailable. Store token in plaintext config file?」(系統 keychain 不可用,常見於 Linux 無 libsecret 或 headless 伺服器)優先修復 keychain/秘密管理服務;CI 或部署平台則在執行期注入最小權限、短效 token。不要接受明文儲存。
6驗證了錯誤的帳號/user switch 切換帳戶,或 /logout 後重新登入

幾個補充細節:

  • 認證用環境變數的優先序COPILOT_GITHUB_TOKEN > GH_TOKEN > GITHUB_TOKEN,適合 CI/headless 環境不走互動登入時使用(延伸細節見第 3 章)。
  • 企業帳號登入指定主機:copilot login --host HOST
  • 表格裡第 3 項的「classic PAT(ghp_ 開頭)被忽略」是新手最容易誤判的一個——CLI 不會明講「你用了舊格式的 token」,只會表現得像沒登入一樣,讓人誤以為是別的問題。看到自己確定登入過、卻一直被要求重新認證,先檢查用的是不是 ghp_ 開頭的舊式 token。

小技巧

表格第 5 項的 keychain 錯誤,在 Docker 容器、CI runner、遠端 headless 伺服器較常見。共用主機、容器映像、shell 啟動檔、備份與版控位置都不應接受明文 token;改用平台的 secret 機制在執行期注入,並設定最小權限與短效期限。

16.4 方案與企業政策擋住你的存取

這一節處理一種特別容易讓人誤會成「設定壞掉」的狀況:其實是你的方案或組織政策根本沒有把 CLI 打開,不是哪裡故障了。

重要提醒:Free 方案本身不含 CLI

GitHub Copilot CLI 的 2026-02-25 GA 公告官方逐字寫明供 「Copilot Pro, Pro+, Business, and Enterprise plans」 訂閱者使用——Free 方案不在列表裡。查證時進一步核對官方的方案功能比較表,CLI 這一項完全沒有出現在任何一欄裡(不是「打勾打叉」的問題,是表格根本沒列這一行)。也就是說,如果你登入的是免費帳號,一直被拒絕存取,答案不是設定錯誤,是 Free 方案本來就不包含 CLI,得升級到 Pro 以上才能用。

企業/組織帳號還多一層政策關卡:

  • Business/Enterprise 使用者需要組織管理員在政策頁面額外啟用,不是訂閱了對應方案就自動能用。
  • Enterprise 層級的政策可以設成「Enabled everywhere」「Disabled everywhere」「Let organizations decide」三選一,前兩者會凌駕底下所有 organization 各自的設定。
  • 2025-11-04 起有一次政策行為變更:如果 enterprise 政策設成「Unconfigured」(未設定),底下 organization 政策的預設值會變成 Disabled,不再是可以自由選擇的中性狀態。這代表不少企業使用者「以為公司已經開通,實際上預設是關的」。
  • CLI 在多個時間點都會檢查政策:認證時、選模型時、功能存取時、設定 MCP server 時,任何一關被擋,都會看到類似「存取被組織政策拒絕,請聯絡管理員」的錯誤訊息。

補充資訊

遇到「存取被組織政策拒絕」這類訊息,第一時間不用懷疑自己哪裡設錯,這通常不是你這台電腦的問題——去找你所屬組織的 Copilot 管理員,請他確認政策頁面的開關狀態,會比自己反覆重裝、重新登入更快解決。

16.5 網路、Proxy 與企業憑證

如果你在公司、學校,或任何「網路被管控」的環境裡用 Copilot CLI,最常見的災情就是它連不上 GitHub。這一節整理標準做法,也附上一個反直覺的官方限制與一個容易誤判的已知 bug。

標準 proxy 環境變數:

export HTTPS_PROXY=http://proxy.corp:8080
export HTTP_PROXY=http://proxy.corp:8080
export NO_PROXY=localhost,127.0.0.1
copilot

也可以帶帳密:http://user:pass@proxy:8080

重要提醒:反直覺限制——proxy 網址不能以 https:// 開頭

官方文件明確寫著:「如果你的 proxy 網址本身以 https:// 開頭,目前 GitHub Copilot 不支援。」("If your proxy's URL starts https://, it is not currently supported by GitHub Copilot.")這條很容易被忽略,因為很多企業內部 proxy 的預設設定就是 https:// 開頭。設定 HTTPS_PROXYHTTP_PROXY 時,先確認你填的網址是 http:// 而不是 https://——就算你要代理的是 HTTPS 流量也一樣,這個限制指的是 proxy 本身的網址格式,不是它代理的內容。

企業自簽憑證/TLS 攔截:很多公司網路會在中間攔截 HTTPS 連線做內容檢查,用的是公司自己的根憑證,這時候 Copilot CLI 會因為不認得這張憑證而連線失敗。Copilot 除了讀作業系統本身的信任庫,也會讀標準 Node.js 環境變數 NODE_EXTRA_CA_CERTS 指到的額外憑證檔——這是 Node.js 生態通用的機制,不是 Copilot 自己發明的:

export NODE_EXTRA_CA_CERTS=/path/to/corp-ca.pem
copilot login

常見對應的錯誤訊息長這樣:certificate signature failurecustom certificateunable to verify the first certificate——看到這幾句,通常就是企業 proxy 在做 SSL inspection,用自己的憑證中間人攔截了連線。

重要提醒:已知社群回報的 bug——無效 proxy 會靜默退出

社群回報過一個很誤導人的狀況(issue #2225):如果 HTTP_PROXYHTTPS_PROXY 指向一個無效的本地 proxy,Copilot CLI 會直接靜默退出,不顯示任何清楚的網路或 proxy 錯誤訊息,很容易讓人誤以為問題出在別的地方(帳號、權限、版本……)。這是社群回報、非官方正式承認的行為,如果你設了 proxy 之後 CLI 一啟動就莫名其妙沒反應直接退出,第一個該懷疑的就是這個——先把 proxy 環境變數清掉試一次,確認問題是不是出在 proxy 設定本身。

16.6 Windows 平台專屬坑

Windows 上跑 Copilot CLI 有一個官方明講的建議路線,跟一個容易踩到的版本門檻。

官方支援 macOS/Linux/Windows 三個平台,但 Windows 有兩條路可以走,穩定度不一樣:

  • WSL(官方推薦):官方原文寫得很直白——「the recommended way to run the Copilot CLI on Windows is through WSL」(在 Windows 上跑 Copilot CLI 的建議方式是透過 WSL)。走這條路,穩定性與 shell 相容性跟原生 Linux 一樣好。
  • 原生 PowerShell(實驗性):需要 PowerShell 6 以上,但 Windows 11 預設只內建 PowerShell 5.1,得手動另外安裝 PowerShell 6+ 才能用原生模式。

重要提醒

如果你在原生 Windows PowerShell 裡跑 copilot,出現各種奇怪的行為(指令沒反應、輸出格式跑掉、快捷鍵不對),先確認兩件事:第一,你的 PowerShell 版本是不是 6 以上(在 PowerShell 裡跑 $PSVersionTable.PSVersion 就能看到);第二,原生 PowerShell 模式本身官方就標成實驗性,行為本來就可能不如 WSL 穩定。真的常常在原生 Windows 上踩到怪問題,最省事的解法就是照官方建議,直接改用 WSL2 跑。

16.7 額度、Quota 與 Context Window

這一節談「用量」——CLI 什麼時候會被擋、額度算法有沒有你意想不到的地方、以及對話視窗滿了會發生什麼事。

重要提醒:CLI 用量跟 IDE 版共用同一個池子,不是各自獨立

Copilot CLI 的用量算「premium request」(新計費制底下算 AI credits 消耗),跟你在 IDE 裡用 Copilot Chat、agent mode、code review 的用量,共用同一份配額池,不是 CLI 獨立一份。官方細節:IDE 的標準 Chat(預設模型)常常不算 premium 消耗,但 CLI 一律算 premium 功能,每次 prompt 通常消耗約 1 個 premium request(不同模型有不同倍率)。這跟本站 Codex CLI 單元第 16 章講的「CLI 跟 ChatGPT 網頁版共用同一份 5 小時額度」是同一種坑,只是共用的對象不同——你在 IDE 裡開太多 Copilot Chat,可能連帶影響到你晚上想在終端機用 CLI 的額度。

2026-06-01 起計費制度大改:從舊制「Premium Request Units」改成新制「GitHub AI Credits」,按 token 計價。1 AI credit = US$0.01。方案月費與內含額度(2026-07 查核,變動快,數字以官方頁為準):

方案月費內含額度
Free$0
Pro$10/月$15 credits
Pro+$39/月$70 credits,含 premium models
Max$100/月$200 credits,優先拿新模型/新功能
Business約 $19/席次/月credits pool + 集中管理
Enterprise約 $39/席次/月pool 更大 + 企業級功能

Context Window 自動壓縮:官方逐字(GA 公告原文):「When your conversation approaches 95% of the context window, Copilot automatically compresses history.」(對話接近 context window 的 95% 時,Copilot 會自動壓縮歷史紀錄)。也可以自己手動下 /compact 指令主動壓縮,不用等系統自己觸發。

/compact

以下是社群回報、官方目前未正式承認的已知怪象,遇到的時候先知道「不是只有你遇到」,比較好判斷方向:

現象社群回報內容狀態
/usage 顯示的用量低估實際消耗issue #1582/usage 顯示扣了 6 次,實際扣掉的額度像扣了 30 次以上community,非官方承認
quota_exceeded(HTTP 402)誤判issue #3431:帳戶明明已啟用「超額付費」,仍被錯誤擋下community,非官方承認
Free 方案額度沒在重置日正確重置issue #2340community,非官方承認
copilot update 撞到 GitHub API rate limitissue #3383#1230:未認證狀態下檢查更新,撞到的是 GitHub REST API 本身的請求限制,跟 Copilot 訂閱額度是兩回事community,非官方承認
context 用量計算異常issue #2496:顯示空的 context 用量,但 token 其實已經超過 100%(甚至到 156%),觸發持續自動壓縮的怪異迴圈community,非官方承認

小技巧

上面那個「copilot update 撞到 rate limit」的案例特別值得記住,因為它最容易被誤判成訂閱額度用完——檢查更新這個動作本身,撞到的是 GitHub API 對匿名/未認證請求的一般限制,不是你的 Copilot 額度出問題。看到跟更新檢查有關的錯誤訊息裡有「rate limit」字樣,先想想是不是這個,再往訂閱額度的方向查。

16.8 回報問題的正確管道

前面幾節列出的社群回報 issue,全部都來自同一個地方:github.com/github/copilot-cli 這個原始碼 repo 的 issue tracker。這也是你自己遇到疑似 bug 時,應該回報的地方——CLI 本身的行為異常、指令跑起來跟文件講的不一樣,優先去這裡搜尋看看有沒有人已經回報過,沒有就開一個新的。

帳號、訂閱方案、組織政策這類問題,性質上不是「程式碼有 bug」,而是帳戶或組織設定層面的事,比較適合透過 GitHub 官方支援管道處理,而不是丟進程式碼 repo 的 issue tracker——這是本書作者依查證所得資訊做的合理歸類(practice/推論),不是逐字照抄某一頁官方文件的說法。

互動模式裡也有一個 /feedback 指令,可以直接在對話裡送出意見回饋:

/feedback

補充資訊

回報任何問題之前,先養成習慣附上 copilot version 的輸出——Copilot CLI 改版速度極快,同一句錯誤訊息在不同版本代表的意義可能完全不同,附上版本號能讓幫你排查的人(不管是社群還是官方)少走很多冤枉路。

16.9 這個模式的邊界:什麼時候不該用

前面十六章教的都是「怎麼把 Copilot CLI 這套常駐終端機 agent 模式用好、出狀況怎麼修」。這一節反過來,誠實講一句前面沒特別點破的話:這套模式不是萬能,有些情況直接手動做,比透過它做更快、更划算。懂得判斷「這次到底該不該動用它」,跟懂得怎麼用它一樣重要,不然很容易變成拿到一把好用的鎚子,看什麼都像釘子。

下面三個場景,都能直接對回第 7 章官方文件逐字列出的「不適用」邊界,以及本章 16.7 節已經講過的用量機制——不是憑空歸類,是把已經查證過的官方界線,往「這整套 agent 模式到底要不要動用」這個更前面一層的問題再延伸一層(這一步延伸屬於本書作者的歸納整理,不是逐字照抄某一頁官方文件的說法):

情境為什麼手動做通常更快依據
單次、答案立刻就能查到的簡單查詢(例如「這個旗標是幹嘛的」「這段語法寫得對不對」) 這種問題不涉及讀寫檔案,不需要跑過信任目錄、核可流程這一整套 agent 迴圈;直接查官方文件或搜尋引擎問一句話,比開一個 session、等它理解 context 再回答要快,還能省下一次跟 IDE 版共用的配額 本章 16.7 節:CLI 每次 prompt 一律算 premium 功能,跟 IDE 版 Copilot Chat/agent mode 共用同一個配額池
已經確定要改哪一行、要改成什麼的小改動(例如修一個 typo、換一個設定值、翻轉一個布林旗標) 官方對 Plan 模式的界線已經講得很白:「不該用:小 bug 修正、單檔案的小改動」。同一個道理往下延伸一層——連 Standard 模式「描述需求 → 等它讀檔案 → 看它跑出 diff → 你按核可」這一輪來回,都比你自己直接在編輯器裡打字要慢;自然語言描述的價值,只有在「你自己都還沒想清楚具體要怎麼改」時才划算 第 7 章 Plan 模式官方逐字「不該用」清單
你想要全程自己一步步做決定、不假手他人的任務 這類任務的重點根本不是效率,是「你自己的判斷要全程在場」;把它交給任何一種 agent 模式(就算是最保守的 Standard),都是在跟這套工具設計的初衷對著幹,不如直接手動做 第 7 章 Autopilot 模式官方逐字 Avoid for:「Open-ended exploration, feature development without a clear goal, or tasks where you want to guide the ongoing work.」

補充資訊:判斷力比熟練度更重要

這本書從第 7 章開始,一直在教你「怎麼帶 Copilot CLI 把事情做好」——三種工作模式怎麼選、核可機制怎麼搭配、best practices 心法怎麼實作。但「這件事該不該透過它做」永遠是動手之前的第一個問題,比「該用 Standard 還是 Plan」更前面一層。上面三個場景不是要你少用 Copilot CLI,是提醒你:用得好的人,不是每件事都丟給它,是清楚知道哪些事丟給它划算、哪些事自己動手比較快。

本章小結

這一章你學會了 GitHub Copilot CLI 出狀況時怎麼自己排查:

  • 第一步永遠是確認身分:你裝的是已經 2025-10-25 停止運作的舊 gh copilot,還是本書教的獨立 copilot 指令——很多「查了半天查不到」的困惑,源頭都是認錯對象。
  • 安裝與版本copilot versioncopilot update 自查,四種安裝管道各有平台限制,npm 需要 Node.js 22+,套件名字是 @github/copilot 不是 @github/copilot-cli
  • 認證疑難排解:官方列出 6 類錯誤訊息與解法,含 ghp_ 舊式 token 被靜默忽略、Linux keychain 不可用兩個最容易誤判的坑。
  • 方案與政策:Free 方案本身不含 CLI(GA 公告寫死在 Pro 以上);企業政策未明確開啟時,2025-11-04 後的預設值是關的,不是中性的。
  • 網路/Proxy/憑證:反直覺限制——proxy 網址不能以 https:// 開頭;企業自簽憑證用 NODE_EXTRA_CA_CERTS;已知社群 bug——無效 proxy 會靜默退出、不給任何清楚錯誤訊息。
  • Windows 專屬坑:官方建議走 WSL,原生 PowerShell 是實驗性功能且需要 PowerShell 6+(Windows 11 預設只有 5.1)。
  • 額度與 Context Window:CLI 用量跟 IDE 版共用同一個 premium request/AI credit 池;2026-06-01 起改按 token 計價的 AI Credits 新制;context window 接近 95% 會自動壓縮,也能手動 /compact;社群回報多個非官方承認的已知怪象(/usage 低估、quota_exceeded 誤判、context 計算異常),遇到先知道不是只有你踩到。
  • 回報問題:CLI 本身的 bug 去 github.com/github/copilot-cli 的 issue tracker;帳號/方案/政策問題走 GitHub 官方支援管道;互動模式裡也有 /feedback 指令可用。
  • 這個模式的邊界:Copilot CLI 不是萬能,單次簡單查詢、已經確定怎麼改的小改動、你想全程自己掌控的任務,直接手動做通常更快——這三個邊界都能對回第 7 章官方文件的「不適用」清單,往下延伸到「這次該不該動用整套 agent 模式」這個更前面一層的判斷。

動手試試

  1. 跑一次 copilot version,記下你目前的版本號,跟本章開頭的 v1.0.71 對照一下差了幾版。
  2. 打開互動模式輸入 /feedback,看看實際跳出來的送出流程長什麼樣。
  3. 如果你的環境用得到 proxy,檢查一下你設定的 HTTPS_PROXY 網址開頭是不是 http://(不是 https://)——這是本章最容易忽略的一條反直覺限制。
  4. 找一次你之前遇過、覺得莫名其妙的錯誤訊息,回頭對照本章 16.3 或 16.7 的表格,看能不能對得上號。
  5. (如果你在 Windows 上)跑一次 $PSVersionTable.PSVersion,確認你的 PowerShell 版本是不是 6 以上;如果不到,想想是不是該考慮改用 WSL。

版本時效提醒

本章所有逐字錯誤訊息、旗標、環境變數、方案價格,都是 2026-07-18 對 GitHub Copilot CLI v1.0.71 的查核快照。Copilot CLI 更新極快,方案價格、政策預設值、已知 bug 的修復狀態都可能隨時變動,使用前請以你電腦上實機執行的結果與官方文件當下內容為最終真相。

本章官方文件參考