個人帳號突然無法繼續請求，舊設定與自動化仍留在 Mac 上。
最快解法：個人使用者直接啟動 Gemini CLI 遷移 Antigravity CLI；企業授權或付費 API 使用者先保留 Gemini CLI，並完成一週雙軌驗收後再決定。
最後更新於 2026 年 8 月 15 日；日期、帳號範圍、遷移能力與權限規則已核對官方公告、遷移文件、安裝文件及權限說明。
這篇適合三類人：依賴 Gemini CLI 日常編碼、需要立即恢復終端工作流的個人開發者；維護 Skills、MCP、Hooks 或無頭程式的高階使用者；以及管理遠端 Mac、SSH 和團隊開發環境的研發負責人。
先確認你的帳號是否真的需要遷移
官方公告確認，自 2026 年 6 月 18 日起，Gemini CLI 停止為免費層、Google AI Pro、Google AI Ultra 相關個人帳號提供請求服務；企業使用 Gemini Code Assist 授權，或以付費 API 金鑰驗證的使用者，不受同等影響。這不是 Gemini CLI 對所有使用者全面下線，企業與 API 路徑仍需按自身授權方式判斷。可參考個人帳號服務調整公告與官方遷移說明。
| 你的登入方式 | 2026 年 6 月 18 日後的判斷 | 建議動作 |
|---|---|---|
| 免費個人帳號 | Gemini CLI 不再提供請求服務 | 立即遷移 Antigravity CLI |
| Google AI Pro／Ultra 個人帳號 | 不應再等待舊 OAuth 路徑恢復 | 先備份，再完成遷移驗收 |
| Gemini Code Assist Standard／Enterprise | 官方表示存取維持支援 | 可暫留，安排一週雙軌測試 |
| 付費 API 金鑰或 Google Cloud 專案 | 不受個人帳號調整同等影響 | 按合規、成本與相容性評估 |
| 需要穩定 CI 或無頭執行 | 不能只看互動式啟動是否成功 | 先測試工作階段、退出碼與回滾 |
為什麼個人帳號不能再用 Gemini CLI？
原因不是你的 Mac、Shell 或專案設定突然損壞，而是官方調整了個人帳號請求服務的承接方式。Gemini CLI 專案仍維持開放原始碼及企業維護路徑，但個人帳號的舊認證入口已不再是可靠的長期方案。
遷移前先封存設定與任務資產
不要第一時間刪除 ~/.gemini。先建立可回滾副本，再分辨哪些資產屬於「檔案可搬移」，哪些資產其實依賴新 CLI 的格式、權限或執行模型。
mkdir -p ~/gemini-cli-migration-backup
cp -R ~/.gemini ~/gemini-cli-migration-backup/
你至少要盤點以下項目：
| 資產 | 需要核對的內容 | 風險 |
|---|---|---|
| Skills | 全域與專案層級路徑、依賴檔案 | 新舊工作區路徑不同 |
| MCP Servers | 伺服器名稱、連線方式、環境變數 | JSON 結構可能需要調整 |
| Agents | 自訂 Agent 定義、工具清單、提示內容 | 不保證格式一對一相容 |
| Hooks | 觸發時機、Shell 指令、退出碼 | 自動匯入不代表 CI 可用 |
| 記憶檔案 | GEMINI.md、AGENTS.md、專案規則 |
需確認新工作區是否讀取 |
| 認證方式 | 個人登入、API 金鑰、企業專案 | 金鑰不應直接寫入設定檔 |
| 無頭程式 | --print、工作階段 ID、輸出格式 |
互動式功能成功也可能不代表腳本相容 |
官方遷移文件表示，Antigravity CLI 首次啟動會偵測既有 Gemini CLI 設定，並提供匯入選項；Skills、MCP、Hooks、Subagents 等核心工作流概念大多有對應能力，但官方也明確提醒並非百分之百功能對等，部分主題與實驗性視覺元件不能一對一搬移。
第一小時：讓自動匯入接受「逐項驗證」
Antigravity CLI 能否自動遷移 Gemini CLI 設定？
可以自動偵測並引導匯入，但你不應把「首次啟動沒有錯誤」當成完整遷移。官方文件列出工作區 Skills、規則、MCP Servers 和部分擴充功能的承接方式，同時也列出 Skills 路徑及 MCP 設定格式的變化。
macOS 可按官方安裝方式執行：
curl -fsSL https://antigravity.google/cli/install.sh | bash
agy
首次啟動時，建議按以下順序操作：
- 保留舊設定副本，不要先改名或刪除
~/.gemini。 - 啟動
agy，記錄匯入清單、跳過項目與警告訊息。 - 確認工作區規則，檢查
GEMINI.md、AGENTS.md是否仍被讀取。 - 確認 Skills 路徑。官方文件指出，全域 Skills 會移至
~/.gemini/antigravity-cli/skills/，專案層級則由.gemini/skills/改到.agents/skills/。 - 重新檢查 MCP 設定。舊設定可能把伺服器寫在
settings.json，新格式則使用獨立的mcp_config.json；遠端服務的url或httpUrl亦可能需要改為serverUrl。 - 用最小測試倉庫驗證檔案讀寫、MCP 呼叫與命令執行。
- 未完成測試前，不要移除 Gemini CLI 的執行檔或舊設定。
| 第一小時檢查 | 通過條件 | 未通過時的處理 |
|---|---|---|
| 專案記憶 | Agent 能讀取既有規則並遵守 | 對照 GEMINI.md、AGENTS.md 的載入位置 |
| Skill | 能被列出並實際執行 | 檢查 .agents/skills/ 或全域新路徑 |
| MCP | 能連線、列出工具、完成非破壞性呼叫 | 重新整理 mcp_config.json |
| 檔案修改 | 只修改測試倉庫指定檔案 | 檢查工作區及 write_file 權限 |
| Hooks | 正確觸發且退出碼符合腳本預期 | 暫停自動化，改用手動執行比對 |
| Agent | 能載入角色、提示和工具限制 | 不要假設舊 Subagent 格式可直接使用 |
提醒： 官方文件的「支援」只代表有承接路徑，不等於你的自訂外掛、Shell Hook、MCP 認證和無頭包裝器都能原封不動執行。
第一天：用同一個任務比較新舊工作流
如果你是企業授權或付費 API 使用者，不要只比較回答速度或介面外觀。最有效的方法，是在同一個測試倉庫中讓 Gemini CLI 與 Antigravity CLI 完成同一組任務。
建議測試流程：
- 閱讀專案規則和目錄結構。
- 修改兩個以上檔案，加入一個可回溯的小功能。
- 執行既有測試與格式化程式。
- 產生差異檢視，確認沒有改動憑證、設定或不相關檔案。
- 呼叫一個只讀 MCP 工具，再測試一個需要人工確認的工具。
- 中斷終端工作階段，重新連線後確認能否恢復。
- 以同一位人工審查者檢查最終差異與測試結果。
不要把官方的「更快」「支援背景工作」直接改寫成你的實測結論。你應記錄人工接管次數、失敗後恢復步驟、錯誤類型、最終測試結果及 CI 退出碼。若沒有本站實測資料，就不要寫精確成功率、延遲或記憶體消耗。
遷移後，MCP、Skills 和自動化程式是否要重寫？
答案是：核心資產可先嘗試匯入，但自訂整合仍要逐項檢查。
官方遷移文件提供 agy plugin import gemini，可把部分 Gemini CLI 擴充功能轉換為 Antigravity Plugins；但文件同時列明，部分元件不能一對一遷移。
你應把以下情況視為「需要改寫或包裝」：
- MCP 設定仍依賴舊 JSON 欄位。
- Hook 依賴特定環境變數、目前工作目錄或舊命令名稱。
- CI 需要指定工作階段 ID、串流 JSON 或固定退出碼。
- Subagent 使用舊格式，或直接依賴未列入匯入清單的工具。
- 自動化程式以互動式 TUI 輸出作為解析來源。
對個人開發者來說，最實際的做法不是逐檔重寫，而是先搬移、再用最小任務找出真正失效的邊界。這能避免把可直接使用的 Skills 和規則全部重做。
第一週：驗收 macOS、遠端 SSH 與權限邊界
Antigravity CLI 在 Mac 和遠端 SSH 環境中是否適合？
Antigravity CLI 官方安裝文件列出 macOS、Linux 和 Windows 支援；在本機登入時可使用瀏覽器驗證，在 SSH 工作階段中則會顯示授權網址，讓你用本機瀏覽器完成登入，再把授權結果帶回終端。可參考官方 CLI 安裝與登入說明。
這解決的是「如何登入」，不是「遠端工作流已經驗收」。你仍要測試：
- SSH 斷線後，工作階段是否能恢復。
- 登入憑證是否落在正確的作業系統鑰匙圈。
- 遠端 Mac 是否能讀取專案、呼叫 MCP 並完成建置。
- Agent 修改程式後，Xcode 建置、簽名與測試是否能在同一台 Mac 上閉環。
- 非互動式執行是否會卡在瀏覽器登入或人工確認提示。
macOS 的價值不只在終端機可啟動。若你的交付目標是 iOS 或 macOS 程式，Xcode 建置、簽名、模擬器測試和鑰匙圈權限都需要完整 Mac 環境。把 Agent 放在只有 Shell 的 Linux 伺服器上，可能能完成程式修改，卻不能完成最後驗收。
不要用全域允許換取少幾次提示
Antigravity CLI 的權限引擎把檔案、命令、網址、未沙盒化執行及 MCP 工具分開管理，並採用 deny、ask、allow 三類規則；衝突時，拒絕優先於詢問，詢問優先於允許。可參考官方權限規則說明。
第一週應建立窄範圍規則：
{
"permissions": {
"allow": [
"command(git)",
"command(npm run test)",
"write_file(src/)"
],
"deny": [
"command(sudo)",
"write_file(.git/)",
"write_file(~/.ssh)"
],
"ask": [
"command(*)",
"mcp(*)"
]
}
}
不要直接加入 command(*) 到允許清單，也不要為了讓 MCP 不再詢問而使用 mcp(*)。官方權限文件指出，工作區內的檔案通常可自動使用，但命令、MCP、外部檔案和網路操作仍應保留詢問或限制範圍。
若你啟用終端沙盒，還要確認命令是否依賴外部網路、絕對路徑或系統工具。官方文件將 macOS 的沙盒建立在 sandbox-exec 上，並提醒沙盒和權限規則會共同影響命令的可見路徑與網路存取。可參考官方沙盒說明。
一週後決定全面遷移或雙軌保留
使用下表作最後決策，不要只用「新工具看起來能啟動」作判斷。
| 使用情境 | 建議方案 | 必要門檻 |
|---|---|---|
| 個人帳號日常編碼 | 遷移 Antigravity CLI | 完成認證、設定、MCP 和回滾備份 |
| 企業團隊 | 先雙軌，再分批切換 | 插件、權限、稽核與 CI 測試通過 |
| 付費 API 使用者 | 可暫留 Gemini CLI | 評估維護期限、成本與新工具相容性 |
| 遠端 Mac + SSH | 以 Antigravity CLI 做工作流驗收 | 斷線恢復、鑰匙圈、Xcode 建置通過 |
| 自動化流水線 | 暫不直接全面替換 | 工作階段、輸出格式、退出碼和密鑰策略穩定 |
你還要把成本拆成四項，而不只是比較當期套餐：
- 官方帳號或 API 用量費用。
- 遷移與維護設定的人工時間。
- CI 失敗、人工接管和回滾的恢復成本。
- 遠端 Mac、SSH 及 Xcode 驗收環境的使用成本。
套餐、用量和企業授權會變動，本文不自行填入未核實的價格。正式採購前，應直接對照當期官方帳號、API 或企業授權頁面；不要把社群討論中的額度、封頂或傳聞價格當成承諾。
正式切換前的驗收表
完成以下項目後，個人使用者可關閉舊工作流；企業與 API 使用者則可按團隊風險分批切換。
- [ ] 個人帳號已完成 Antigravity CLI 登入。
- [ ] 舊
~/.gemini已封存，且能在需要時還原。 - [ ] 全域與專案 Skills 已確認新路徑。
- [ ] MCP Server 已完成連線、權限和環境變數驗證。
- [ ] Hooks、Agents 和無頭程式已逐項測試。
- [ ] 最小測試倉庫完成多檔修改、差異審查和測試。
- [ ] SSH 斷線後能恢復，或已有明確人工接管流程。
- [ ] macOS 上的 Xcode 建置、簽名和測試均已驗收。
- [ ]
command、write_file、mcp等權限沒有不必要的全域允許。 - [ ] 已寫下回滾條件，例如 MCP 無法連線、CI 退出碼改變或 Xcode 建置失敗。
- [ ] 團隊成員知道新認證方式、設定位置和故障處理責任。
如果你目前的 Mac 無法連續提供 macOS、SSH 和 Xcode 驗證，先不要因為一次登入成功就長期採購硬體。你可以先閱讀遠端 Mac 算力方案，再按測試週期準備環境；若團隊在亞洲或北美有不同連線需求，也可比較香港遠端 Mac 節點與維珍尼亞遠端 Mac 節點。
對個人帳號而言，繼續等待舊 Gemini CLI 認證路徑，實際缺點是請求服務已中斷、舊工作流沒有可承諾的恢復時間，而且你仍要自行承擔設定相容與權限重驗。對企業或 API 使用者而言，立即全面切換則可能打斷既有 CI、MCP 和稽核流程。較穩妥的做法是：個人使用者現在遷移；企業與 API 使用者用一週雙軌測試控制風險。若你缺少能長時間維持 macOS、SSH、Xcode 建置的環境，再考慮用 MACCOME 按測試週期準備遠端 Mac，而不是在遷移驗收前先承擔長期設備成本。