Claude Code 和 Codex 之間，哪些 Memory 真的接得上？

Claude Code 和 Codex 輪流使用時，有個很實際的問題：在一個用戶端存下的 Memory，能不能在另一個用戶端的新工作階段讀到？我們用明確 MCP 工具呼叫，在 Cairn（cairn.ink）從固定原始碼啟動的本機開發預覽（source-run local preview）裡測了這個範圍很小的案例。結果支持這個設定下的來源接續，沒有測兩個用戶端會不會在背景自動擷取，也沒有測它們能不能從自然語言問題想起正確內容。

怎麼測

測試日期是 2026-11-08。用戶端版本是 Claude Code 2.1.319 和 Codex 0.166.0；local MCP source 固定在 ad274b6，資料庫是新建的合成資料庫，測試記錄都設成 project-scoped。

我們先在 Claude Code 用明確工具呼叫存一條無害的合成偏好，結束那個工作階段，再開新的 Codex session 讀取對應來源。接著用另一筆合成測試資料反向測試，從 Codex 存，再由 Claude Code 讀。兩個方向都讀到預期來源。錯誤 project control 重用該方向的正向 project-scoped 記錄，改用另一個實際存在的不透明 project ID；兩個來源清單都為空。接收端的查詢、工作目錄和 repo 都沒有預期答案。

這些都是明確工具呼叫。read_memory_sources 會列出目前 local scope 裡保留的來源，不會替問題做語意匹配或生成答案。這個 pinned 版本有哪些工具、各自能做什麼，寫在固定版本的 standalone MCP 說明。

安全重做一次

請用一次性的 local 環境，自己填入私有資料庫、owner 和不透明 project ID。不要拿 production 資料庫或真實個人筆記測試。Native client 使用既有訂閱，因此 local database 不代表離線；本次沒有 hosted Cairn write。

1. 固定同一個 source commit，用新建的合成資料庫啟動 local preview。
2. 在用戶端 A 以明確 MCP 呼叫存一條不敏感的 project-scoped 合成測試資料。預期答案要留在用戶端 B 的提示、repo、工作目錄與對話紀錄以外。
3. 結束 A 的工作階段，在 B 開新 process 或 session，明確呼叫 read_memory_sources，檢查回傳來源和 Source Receipt。另加 inspection 可以是之後重做時的檢查步驟，本次跨用戶端結果沒有呼叫它。
4. 換另一筆合成測試資料測反方向。錯誤 project control 重用該方向的正向資料，改用測試環境裡確實存在的另一個不透明 project ID。
5. 記下用戶端版本、source、scope、呼叫和結果，並把來源清單讀取與語意 recall 分開記錄。

這個結果只屬於本機開發預覽。Local owner 和 project 由 server 啟動設定提供，不是 hosted 帳戶的認證邊界。我們沒有測 hosted 同帳戶讀取、語意 recall 品質、自動擷取或自動回想。固定版本的來源文件也把這組能力描述為開發預覽，不是 hosted 整合。

來源能證明什麼

Memory 是私人、由使用者擁有的記憶；Memory Scope 決定它能在哪個範圍被回想。Source Receipt 能說明 Memory 從哪裡來，不能證明內容正確，也不能保證今天仍適用。這個 pinned 版本的檢視欄位和範圍規則，見local store contract。Knowledge Card 是另一種文件，要分享出去還需要人另外決定。本次沒有建立或分享 Knowledge Card，也沒有 hosted Cairn write。

結果很具體，但範圍有限：在這個 source 版本和兩個用戶端版本中，兩邊都能在新工作階段明確讀到同一個 project-scoped 合成來源，錯誤 project controls 也保持空白。這給工程師一個可以自己檢查的步驟，還不能把 local 來源清單當成 hosted 記憶或模型回想的證據。

設定方式和各用戶端操作，請看跨 AI 工具使用私人記憶的 Learn 指南。