想關掉 GitHub Copilot Memory，先到 GitHub 個人設定的 Copilot Memory 選擇 Disabled；只想停止某個 Repository 的共享 Facts，則由 Repo 管理員到 Repository Settings > Copilot > Memory 關閉。 兩個開關管的範圍不同，關掉 Repo 功能也不會自動刪除已存在的 Facts。
Copilot Memory 目前仍是 public preview。它能讓 coding agent、code review、CLI 與支援的 IDE 在新工作階段沿用偏好和專案資訊，省下重複解釋的時間；但錯誤的命名慣例、過期架構或敏感內部資訊也可能被重複帶入後續任務。使用前要先知道資料屬於誰、誰看得到，以及如何確實刪除。
Copilot Memory 會記住什麼？
GitHub 把記憶分成兩類，不應混在一起管理。
| 類型 | 適合保存 | 使用範圍 | 主要管理者 |
|---|---|---|---|
| User-level preference | 回答語言、測試偏好、工具習慣、Git 慣例 | 只供本人使用，可跨 Repository | 使用者；企業也可能依授權擁有稽核與刪除權 |
| Repository-level fact | 架構規則、常用測試命令、目錄責任、命名慣例 | 該 Repository 的 Copilot 使用情境 | Repository owner |
個人偏好不該替整個團隊下規則，Repo Facts 也不能取代 README、CONTRIBUTING.md、Architecture Decision Record 或測試設定。Memory 適合加速找回脈絡，正式工程規則仍要存在可 review、可版本控制的位置。
對 Business 與 Enterprise 使用者還多一個 billing entity。GitHub 會依目前使用 Copilot 的組織或企業保存與取回個人偏好；同時擁有多個授權的人，可能需要指定預設 billing entity。這能隔離不同組織的偏好，但管理員仍應實測切換組織後是否只讀到預期範圍。
查看、刪除與停用：四個入口不要搞混
個人帳號：一次關閉個人偏好與 Repo Facts 使用
在 GitHub 點右上角頭像，進入 Copilot settings，於 Features 找到 Copilot Memory，選擇 Enabled 或 Disabled。GitHub 文件說，個人付費方案預設可啟用；受組織或企業管理的方案要先由管理員允許，使用者仍可自行退出。
想刪除個人偏好，進入 Copilot settings > Memory，逐項查看與移除。只在聊天裡說「忘記這件事」不等於資料一定刪除；GitHub 的流程是把你導向正確設定位置，並在支援處降低該記憶的評價，最後仍應回設定頁確認。
Repository：停用不等於清空
Repo owner 可到 Repository Settings > Copilot > Memory 查看、刪除 Repository-level facts，或關閉該 Repo 的 Memory。關閉後不再儲存或讀取 Repo Facts，卻不會自動刪掉既有項目，User-level preferences 也不受影響。
若團隊發現錯誤的部署命令、已淘汰目錄或敏感 URL，應立即刪除對應 Fact，並檢查正式文件與近期 PR 是否也含相同錯誤。只關開關、等待它自然消失，會留下無法確認的窗口期。
Copilot CLI：用指令控制目前狀態
CLI 可使用：
/memory show
/memory on
/memory off選擇會跨工作階段保留。第一次在新電腦、容器或公司帳號使用 CLI 時，先跑 /memory show，不要假設 IDE、GitHub 網頁與 CLI 的狀態一定相同。若要讓 Agent 讀 Repo、執行命令或開 PR，也應搭配 GitHub Copilot 費用與模型選擇指南檢查方案、權限與 AI Credits。
組織與企業：政策、匯出與大量刪除
Business／Enterprise 管理員可以控制 Copilot Memory 是否可用。GitHub 也提供匯出 user-level preferences 供稽核，以及大量刪除由該授權建立的偏好。政策套用可能受使用者同時隸屬多個組織或企業影響，正式部署前要用測試帳號驗證實際結果，而不是只看管理頁顯示 Enabled。
最小治理做法是每月抽查三件事：新增了哪些 User preferences、哪些 Repo Facts 被多人使用、離職或轉組成員的資料是否仍由正確 billing entity 管理。政策變更要進 audit log，且由明確角色負責清理。
28 天會自動過期，為什麼仍要人工清理？
GitHub 文件表示，未使用的 Fact 或 preference 會在 28 天後自動刪除；如果 Copilot 成功驗證並使用某項記憶，計時可能重設。從未合併的 Pull Request 擷取到的 Facts 也可能被保存，但使用前會再確認目前 codebase 是否仍支持該資訊。
因此，「28 天後會消失」不能當成事故處理。錯誤資訊如果持續被驗證或使用，就可能繼續存在；憑證、客戶名稱、內部位址與安全規則一旦誤存，也不應等待到期。這類事件應立即刪除、輪替可能外洩的秘密，並檢查 Copilot 對話、PR 和日誌。更完整的權限與記錄做法可接著看 AI Agent 安全工程。
JetBrains 的 Memory 與 Ollama 是兩件事
GitHub 8 月 11 日更新讓 JetBrains 裡的 Copilot Memory 能跨 Agent Chat 工作階段保留並取回資訊，同時加入 Ollama 作為 BYOK provider。Ollama 可讓 JetBrains 選擇本機模型；GitHub 的 BYOK 文件也說，本地 BYOK 金鑰在 client side 處理，企業或組織可用政策停用這項能力。
這兩個功能同時出現在更新裡，資料邊界卻不同。把推論送到本機 Ollama，不代表 Copilot Memory 也自動只存在本機。 這是依兩套功能文件做出的架構判斷：Memory 仍有 GitHub 帳號、Repo 與 billing entity 的管理路徑，BYOK 則決定模型推論供應端。若需求是「程式碼與偏好都不得離開裝置」，應先停用 Memory、確認 IDE 網路行為，再依 Ollama 地端模型指南測試本機模型，不要只看到 Ollama 就判定整條流程離線。
本機模型也要記錄參數量、量化版本、Context 上限與工具呼叫支援，再用同一組 Repo 任務測速度和成功率。7B、14B 與更大模型需要的 RAM／VRAM 不同；免付雲端 API 費只代表帳單位置改變，電力、硬體、下載、更新與除錯時間仍是成本。硬體不足或 Agent 工具相容性不穩時，較小模型能跑起來也不代表足以取代 GitHub-hosted model。
團隊上線前的 10 分鐘檢查
- 用一般成員帳號確認 Copilot Memory 是否預設開啟，以及能否自行退出。
- 查看個人 preferences，刪除可疑、過期或過度寬泛的指令。
- 由 Repo owner 查看 Facts，確認每一項仍能在目前 codebase 找到依據。
- 測試關閉 Repo Memory 後，既有 Facts 是否仍留在管理頁並完成清理。
- 在 CLI 執行
/memory show，核對它與網頁政策是否一致。 - 針對 Business／Enterprise 匯出一份 preferences，確認稽核負責人與保存期限。
- 使用 JetBrains + Ollama 時，分開記錄模型請求去哪裡、Memory 由誰擁有。
- 把團隊正式規則移到版本控制文件，不讓 Memory 成為唯一副本。
常見問題
關閉 Repository Memory 會刪除原本的 Facts 嗎？
不會。GitHub 說關閉後會停止儲存與讀取 Repo Facts，但既有 Facts 不會自動刪除。Repo owner 要到 Repository Settings > Copilot > Memory 查看並移除。
Copilot Memory 的資料會永久保存嗎？
GitHub 文件表示，未使用的 Fact 或 preference 會在 28 天後自動刪除；成功驗證與使用可能重設期限。敏感或錯誤資料不應等待自動過期，應立即人工刪除並處理可能的外洩。
用 Ollama 後，Copilot Memory 也會留在本機嗎？
不能這樣推論。Ollama BYOK 決定模型推論供應端，Copilot Memory 仍有 GitHub 帳號、Repository 與 billing entity 的管理機制。需要全本機資料路徑時，先停用 Memory 並實測網路流量和 IDE 行為。