push 突然失敗說 repo 不存在：兇手是 gh 的全域帳號

先講症狀。同一個終端機、同一個 repo，五分鐘前 git push 才成功，下一次卻噴出：

remote: Repository not found.
fatal: repository 'https://github.com/.../....git/' not found

repo 當然存在——瀏覽器開著它的頁面，上一筆 commit 就在眼前。但錯誤訊息說它不存在。

天真解法為何錯：查 remote、查 repo 都白查

看到「not found」，直覺的排查順序是：remote URL 打錯了？repo 被改名？被刪了？權限被撤了？

我們把這條路走完了，全部沒中。這正是這個錯誤訊息的陷阱——它把你的注意力全部引導到 repo 身上，但問題根本不在 repo。

追兇：gh auth switch 是全域的

真正的兇手是帳號。我們用 gh CLI 管理多個 GitHub 帳號——接案工作者的常態：自己的帳號、客戶組織的帳號、專案專用的帳號。不同 repo 屬於不同組織，各自要求對應的身分，切換靠 gh auth switch。

平常這套運作得很順，順到讓人忘記它的存在——正因為切換太順，帳號變成一個沒有人盯著的隱形狀態。

關鍵在於：gh auth switch 切的是整台機器的 active account，存在系統鑰匙圈裡——不是這個 repo 的、也不是這個視窗的。任何一個視窗、任何一個並行的工作階段切了帳號，所有視窗一起被切。

我們的情況：另一個並行的工作階段為了處理別的專案切走了帳號，而新帳號對這個私有 repo 沒有權限——push 就這樣掛了。五分鐘前成功、五分鐘後失敗，中間唯一改變的是一個看不見的全域狀態。

為什麼 GitHub 用 404 不用 403

沒權限應該回 403（禁止存取）才對，為什麼是 404（不存在）？

這是 GitHub 的刻意設計：**對沒有權限的人，連「這個私有 repo 存在」本身都是不該洩漏的資訊。**如果回 403，攻擊者就能用窮舉法探測哪些私有 repo 存在。所以一律回 404——安全上正確，除錯上誤導。

錯誤訊息說「不存在」的時候，先問一句：是對誰不存在？

修法：把帳號檢查放進 push 前

解法本身很短：push 前先 gh auth status 確認 active account，不對就 gh auth switch 切回來。排查順序也重排了：遇到這個錯誤，第一步查帳號、第二步才查 remote——順序反過來，你會把時間全花在不可能的方向上。

更重要的是把兩件事寫成明文。第一件，「哪個 repo 用哪個帳號」記進專案的常備知識——不管是人還是 AI 接手，動手前都查得到答案。第二件，把這個坑登進專案的陷阱登記簿（我們用 flightwake 管理這類「會再咬人一次」的知識），條目寫明：看到 Repository not found，先查帳號，不要去查 remote。

下次再遇到，排查時間從半小時變三十秒。這比修好這一次值錢得多——尤其當你和 AI 協作開發時：agent 遇到 404 同樣會往「repo 不存在」的方向排查，把正確方向寫成可查的紀錄，人和 AI 都受益（我們替客戶建的系統也吃同一套紀律，見案例研究）。

給多帳號工作者的三個自我檢查

1. **你能在十秒內說出現在的 active account 是誰嗎？**不能的話，你遲早會用錯身分 push——或更糟，用錯身分留下 commit 紀錄。
2. **並行的工作階段之間，有共享的全域狀態嗎？**帳號、環境變數、憑證快取——任何一個都可能讓「剛剛還能動」變成「突然壞掉」。
3. **上一次踩的坑，有沒有寫在下一個人（或下一個 AI）找得到的地方？**沒有的話，同一個坑每換一個人就要重踩一次。

如果你的團隊也常在多帳號、多專案之間切換，想把這類隱形狀態管起來——歡迎聊聊你們的工作流程。

預約 30 分鐘免費流程診斷 →