Zed 編輯器把你的密碼原封不動寫進 log 檔：9/4 的 1.18.1 版才修好，一行指令自己檢查
文章最後更新：2026-09-05
如果你用 Zed 這個編輯器，而且會用它連「dev container」（一種把開發環境包進 Docker 的做法），那你電腦裡有一個檔案可能正躺著你的 API 金鑰、資料庫密碼——而且是沒有遮蔽的明碼。
這件事 9 月 1 日被回報、9 月 4 日隨 Zed 1.18.1 修好。以下是白話版的來龍去脈，以及你現在該做的事。
一句話講完問題
Zed 在連進 dev container 的時候，會執行一長串 docker exec 指令。這串指令裡包含你設定的每一個環境變數，格式像 -e GH_TOKEN=你的真實金鑰。
問題在於：Zed 把「整串指令」原封不動寫進自己的日誌檔 Zed.log，一次寫在 DEBUG 等級，連線失敗重試的時候還會再用 ERROR 等級寫一次。
回報者在官方 issue 裡的原話重點是：Zed.log 這個檔案，一般人根本不覺得它敏感，預設權限是所有人可讀，而且它正是大家出問題時直接複製貼上到 bug 回報裡的那個檔案。
也就是說，風險有兩層：
- 金鑰以明碼躺在你自己的硬碟上（多人共用的機器、備份、同步資料夾都可能一起帶走）。
- 你熱心回報 bug、把 log 貼上網的那一刻，等於公開發布金鑰。
誰會中招？誰不會？
| 你的情況 | 會不會受影響 |
|---|---|
| 用 Zed 連 dev container，而且環境變數裡有金鑰或密碼 | 會（升級到 1.18.1 前） |
| 用 Zed 但沒在用 dev container | 不會 |
| 用 dev container，但環境變數裡沒放任何機密 | 不會外洩機密，但 log 一樣被寫得很長 |
回報者實測的環境是 Zed 1.17.2（Linux），dev container 走 docker compose、機密以 containerEnv 或 compose 的 environment 傳進去。官方修正被合併進穩定版的時間是 2026-09-04，對應的版本是 1.18.1——這一版的更新說明裡就寫著「修正 dev container 環境變數被完整記錄」。
自己檢查：一行指令
Linux 上 Zed 的日誌預設放在 ~/.local/share/zed/logs/Zed.log。直接搜尋你自己會用到的變數名稱：
grep -n -E "GH_TOKEN|API_KEY|SECRET|PASSWORD|TOKEN" ~/.local/share/zed/logs/Zed.log
- 沒有任何輸出：你這台機器目前沒有被記錄到（也可能是日誌已經輪替掉了，舊檔案通常在同一個資料夾）。
- 有輸出而且看得到完整的值：你中了，往下看三件事。
順帶一提，這也是為什麼修好之後的版本會把值換成 <redacted>——官方的修法是在把指令寫進日誌之前，先把每個 -e 名稱=值 的「值」蓋掉。
中了要做的三件事（順序不要顛倒）
第一件：先撤銷、重發金鑰，不是先刪 log。 只要金鑰曾經以明碼躺在硬碟上、甚至已經被貼到網路上，刪掉檔案不會讓它變安全。GitHub token、雲端服務金鑰、資料庫密碼，全部重新產生一份，舊的作廢。
第二件：升級 Zed 到 1.18.1 或更新版本。 沒升級的話，你下次連 dev container 又會再寫一次。
第三件：清掉舊日誌。
確認新金鑰上線之後，把 ~/.local/share/zed/logs/ 裡的舊日誌刪掉，順便檢查你有沒有把它同步到雲端硬碟或備份。
還有一個長期習慣：任何時候要貼 log 上網求助，先自己搜一遍有沒有金鑰。這次事件裡，連回報 bug 的人自己都是手動把 log 裡的 token 遮掉才敢貼。
這件事的通則：日誌是最常被忽略的外洩管道
密碼不是只會從 GitHub 的 commit 外洩。日誌檔、錯誤訊息、崩潰報告、AI 工具送出去的「上下文」，都是同一類風險：你以為它只是除錯資訊，實際上它把環境完整拍了一張照。
如果你用的是 GitHub Copilot 這類會讀取專案檔案的工具，同樣的道理適用在「哪些檔案不該被 AI 讀到」——我們另外寫過 Copilot 內容排除設定的實作教學，可以一起看。
常見問題
我用的是 macOS 或 Windows，也有這個問題嗎？
問題出在 Zed 產生 docker exec 指令、再把指令寫進日誌的那段程式，跟作業系統無關；差別只在日誌路徑不同。官方回報單上實測的環境是 Linux，其他系統官方沒有逐一列出，本站不推估。最保險的做法一樣：升級到 1.18.1，然後搜一遍自己的日誌。
我從來沒貼過 log 給別人，是不是就沒事？
風險降低，但沒有歸零。明碼金鑰留在硬碟上，只要那台機器是共用的、有備份到雲端、或曾經被其他程式讀取，就仍然是暴露狀態。金鑰重發的成本通常只有幾分鐘，值得做。
為什麼一個編輯器要把整串指令寫進日誌？
因為對開發者除錯很有用——連不上 container 的時候，看到完整指令就知道哪裡錯了。這次的修法不是不記錄，而是記錄但把值蓋掉：指令結構還在，敏感值變成 <redacted>。這是處理這類問題的標準做法。
資料來源：Zed 官方 issue #63569「Dev container docker exec command is logged in full, leaking environment secrets into Zed.log」（2026-09-01 開單、已關閉）、修正 PR #63735（cherry-pick 至穩定版，2026-09-04 合併）與 #63606、Zed 官方穩定版發行說明 zed.dev/releases/stable（1.18.1，2026-09-04）；皆為 2026-09-05 直讀。
證據等級：官方一手（原始碼倉庫與官方發行說明）。受影響版本範圍官方未逐一列舉，本文只寫回報者實測的 1.17.2 與修正版本 1.18.1，不推估中間版本。
延伸：Zed 工具頁、Copilot 內容排除設定教學
