Antigravity CLI（Gemini CLI）Status Line 亂碼修復

發布：2026/06/17 更新：2026/11/04

目錄7 個章節

TL;DR

Status line 亂碼的根本原因是 settings.json 用 powershell（PowerShell 5.1）執行腳本。5.1 讀無 BOM 的 UTF-8 腳本會改用 Big5 解碼，進度條字元 █ 把後面的 $ 吃掉，顏色碼就變成純文字印出來，跟終端機支不支援 ANSI 無關。解法：把指令改成 pwsh（PowerShell 7），重開 Antigravity CLI，其他都不用動。隔天還發現另一個更深的坑：Session Context 卡在 45% 不會動，是因為腳本解析的 JSON 欄位跟 Antigravity CLI 實際送出的格式不一樣，詳情看文末。

💡 2026-11-04 更新：修正亂碼的根本原因。如果你照舊版文章加過 Add-Type 開啟 ANSI 那段（腳本或 PowerShell profile），可以拿掉，它對亂碼沒有幫助，而且每次開 PowerShell 都要編譯 C#，我的電腦實測多花約 1.6 秒。

平常我主要都是用 Claude 搭配 Codex，但最近 token 燒得有點兇，又不想花錢升級，只好先用 Gemini CLI 頂著。

把它更新成 Antigravity CLI 之後，我想叫出下方那條 status line 看用量，結果 /statusline 叫出來整排都是亂碼（可惜忘記截圖）。

追到最後，問題跟終端機支不支援顏色一點關係都沒有，是腳本的編碼被讀錯了。

為什麼會出現亂碼？

不是終端機不支援顏色，是腳本的編碼被讀錯，顏色碼前面的 $ 被吃掉了。

亂碼長這樣：

Session Context: ??([char]27)[0m??([char]27)[0m...

先講 ([char]27) 是什麼。腳本要讓 status line 有顏色，得先送出 ESC 這個控制字元（ASCII 第 27 號），後面接 [0m、[38;2;2;223;130m 這類代碼，終端機才知道要上色。PowerShell 裡產生 ESC 的寫法是：

"$([char]27)[0m"    # 產生 ESC 字元 + "[0m"

重點來了：你仔細看亂碼，([char]27) 是以純文字的形式印出來的，前面的 $ 不見了。也就是說輸出裡根本沒有 ESC 控制字元，腳本從頭到尾沒有產生過它。

所以這不是 ANSI 或 VT 沒開的問題，是 $ 在某個環節被吃掉了。

真正的問題出在哪？

問題出在 settings.json 這個設定檔（路徑：C:\Users\<你的使用者名稱>\.gemini\antigravity-cli\settings.json）：

"statusLine": {
  "type": "command",
  "command": "powershell -ExecutionPolicy Bypass -File C:/Users/.../antigravity-cli/scratch/custom_status.ps1",
  "enabled": true
}

這裡呼叫的是 powershell，也就是 Windows PowerShell 5.1，而不是 PowerShell 7（pwsh）。光這樣還不會出事，要再加上兩個條件：

custom_status.ps1 存成 UTF-8 無 BOM，裡面有進度條字元 █。
PowerShell 5.1 讀到無 BOM 的腳本時，不會當成 UTF-8，會改用系統語系的編碼。繁中 Windows 就是 Big5（CP950）。

█ 的 UTF-8 是 3 個 byte（E2 96 88），但 Big5 是兩個 byte 一組讀。前兩個 byte 湊成一組，剩下的 88 就跟後面的 $ 湊成一組，$ 就這樣被吃掉了。

所以腳本裡的 "█$([char]27)[0m"，在 5.1 眼裡變成 ?? 加上純文字 ([char]27)[0m。沒有 $，([char]27) 就不會被當成運算式執行，ESC 字元當然也不會出現。

我用同樣寫法的小腳本做了三組測試：

執行環境	腳本編碼	輸出
PowerShell 5.1	UTF-8 無 BOM	`??([char]27)[0m`，沒有 ESC 字元
PowerShell 5.1	UTF-8 有 BOM	`█` + ESC + `[0m`，正常
PowerShell 7	UTF-8 無 BOM	`█` + ESC + `[0m`，正常

同一支腳本，只差在誰來跑、檔案有沒有 BOM。

怎麼修？

只要改 settings.json 一個檔案：把 command 從 powershell 改成 pwsh，重開 Antigravity CLI 就好。

"command": "pwsh -ExecutionPolicy Bypass -File C:/Users/.../antigravity-cli/scratch/custom_status.ps1"

PowerShell 7 讀無 BOM 的腳本預設就是 UTF-8，█ 不會被拆錯，$ 也就不會被吃掉。腳本本身一個字都不用改，也不用去碰 PowerShell profile 或登錄檔。

💡 如果你的環境只能用 5.1，可以把 custom_status.ps1 另存成 UTF-8 with BOM。上面的測試表只驗證到這樣腳本能正確產生 ESC 字元，我沒有實際在 5.1 上看過 status line 的畫面，要用的話自己確認一下。

怎麼驗證有沒有修好？

開一個終端機，用 pwsh 直接跑一次腳本：

'{}' | pwsh -ExecutionPolicy Bypass -File "你的 custom_status.ps1 路徑"

輸出裡沒有 ([char]27) 這串字樣，重開 Antigravity CLI 後 status line 也正常，就是修好了。

之後又出現亂碼怎麼辦？

先看畫面上的亂碼長什麼樣子，兩種原因長得不一樣：

出現 ([char]27) 這串文字：是編碼問題。檢查 settings.json 是不是用 pwsh、腳本編碼對不對。
出現 ←[0m 這類控制碼：才可能是 VT 沒開，跟編碼無關。

到這邊我以為大功告成了，結果隔天就發現這個 status line 根本是假的，不管我怎麼用，數據看起來都長一樣。上網查了一下，發現有人遇過一樣的問題，我把官方文件直接餵給 Antigravity CLI（模型切到 Sonnet），這次才真正解決。

隔天的修復紀錄：數據卡死、進度條不動

新問題：Session Context 永遠卡 45%

亂碼問題解決後，我發現 status line 上的數據完全不會動：

Session Context 永遠停在 45%
5h 跟 7d Usage 顯示固定數值，沒有進度條

根本原因：JSON 欄位對不上

腳本是照 Claude Code 預期的 JSON 格式寫的，但 Antigravity CLI 送出的 JSON 結構完全不一樣。

Context 解析錯誤

腳本預期讀取 token_percent 或 context_percent
實際上 Antigravity CLI 把數據放在 context_window.used_percentage（例如 21.4992，是百分比數值，不是 0~1 的比例）
讀不到預期欄位 → 腳本觸發 fallback，直接把數值寫死成 $percent = 45

5h / 7d 額度解析錯誤

腳本自己用本地檔案實作了一套 mock 機制去「推算」使用量
但 Antigravity CLI 其實已經在 JSON 裡直接給了精準額度，放在 quota 物件：
- Claude 等第三方模型 → 3p-5h、3p-weekly
- Gemini 模型 → gemini-5h、gemini-weekly
- 都附帶 remaining_fraction（剩餘比例）跟 reset_time（重置時間）
腳本完全沒用官方給的精準數據，顯示的是本地算出來的不準確固定值

怎麼修：重寫 `custom_status.ps1`

動態判斷模型與額度來源：檢查 $data.model.id，含 “gemini” 就讀 quota."gemini-5h"，否則讀 quota."3p-5h"，確保額度永遠對應目前在用的模型
正確換算使用量百分比：used_percentage = (1 - remaining_fraction) * 100
正確讀取 Context 資訊：改讀 context_window.used_percentage、context_window.total_input_tokens、context_window.context_window_size
加上 5h / 7d 進度條：把進度條渲染邏輯抽成共用的 Render-Bar 函式，套用在 Session Context、5h Usage、7d Usage 三個指標上，都能顯示綠 → 黃 → 紅的 TrueColor 漸層進度條

雖然還沒做到跟 Claude 一樣漂亮，但起碼數據終於正常跳動了😁…要做到跟 Claude 一樣漂亮，改天再研究還有什麼參數可以調。

結論

回頭看，亂碼是編碼問題，數據不動是 JSON 欄位問題，這是兩件事。再深的我就懶得研究了，那跟我工控人無關(我沒興趣研究)，後面我覺得腳本 JSON 欄位對上，應該就是對了，不過我覺得最終還要自己去上網找腳本貼給它才懂挺煩人了，使用 CLAUDE 改 status line 的過程就很順。不過這次的問題也算是個經驗了，至少知道了亂碼的根本原因是什麼，以後遇到類似問題就知道怎麼解了。