Codex thread snapshot 怎麼分享？先檢查唯讀範圍與 secrets

先分清楚 snapshot 的三個邊界#

OpenAI 的 release notes 將這項能力描述為 local Codex thread 的 read-only snapshot，且所有 Codex plan 都可使用。實際分享前，先用下面三個問題決定它適不適合當交接材料：

如果需要的是共同編輯、持續同步或讓對方直接操作 repository，thread snapshot 不是那個工具；它只分享可讀的當下紀錄。

分享前先做一次內容審查#

OpenAI 說 Codex 會遮罩已知的 secret pattern，但這不是「所有敏感資料都會自動消失」的保證。分享按鈕出現後，先把 snapshot 當成即將公開的文件，至少檢查以下內容：

• command、diff 與 log 是否包含 API token、cookie、SSH 路徑或內網主機名稱。
• .env、設定檔、錯誤輸出與測試 fixture 是否把客戶資料或一次性憑證帶進對話。
• prompt 或 instructions 是否揭露內部規則、供應商名稱、未公開的架構決策。
• 工具呼叫結果是否包含完整檔案內容，而不是只有必要的摘要。
• thread 中較早的訊息是否仍在分享範圍內，造成「最後一則訊息看起來安全，但前文含敏感資料」。

已知 pattern 遮罩是一層輔助，不是 review 的替代品。尤其是自訂 token 格式、短期測試密碼、內部 URL 與業務資料，未必符合自動遮罩能辨識的形式。

個人與工作區連結怎麼選#

可以用分享對象和資料敏感度做簡單決策：

個人帳號的連結只要被轉寄就可能被其他人查看；工作區限制也不代表內容可以不審查。權限範圍與內容敏感度是兩個不同的檢查欄位。

分享後怎麼留下可撤銷的紀錄#

建立 snapshot 後，建議把連結當成一個需要管理的外部輸出：

1. 在交接紀錄寫下 snapshot 的用途、建立日期、原 thread 目前的 commit 或任務狀態。
2. 不要把分享 URL 放進公開 issue、repository README 或會被搜尋引擎抓到的文件。
3. 在 ChatGPT 的 Data controls > Shared links 檢查現有連結，確認不再需要時撤銷。
4. 如果任務後來出現 secrets、客戶資料或錯誤分享，先撤銷連結，再輪替可能已經暴露的憑證。

OpenAI Help Center 說明，shared links 可以在 Data controls 中管理與刪除；不要等到需要找回連結時才第一次盤點。對企業或工作區環境，還要依組織自己的保存、外部分享與 incident 流程處理。

若你要分享的是可重複使用的工具或外部連線設定，請另外查看 Codex plugins、skills 與 apps 的權限邊界，不要把一次性 thread snapshot 當成正式的權限文件。

snapshot、diff 與 repository access 不要混為一談#

Codex thread snapshot 只讓接收者看到分享內容；它不會授予對方 repository、工作區資料夾或外部 app 的操作權限。反過來說，snapshot 也可能包含已經出現在 thread 裡的檔名、程式碼片段、命令結果與工具輸出，所以「沒有給 repository access」不等於「沒有資料外流風險」。

如果 review 只需要知道改了哪些檔案，優先分享經過人工整理的 diff 摘要；如果需要理解 agent 為什麼做某個決定，再分享去除敏感內容的 snapshot。每一種輸出都應該有明確的讀者、範圍與撤銷方式。

結論：把 snapshot 當成不可自動更新的對外文件#

Codex snapshot 的價值是降低任務交接摩擦，但它的安全邊界很清楚：分享的是某個時間點的唯讀內容，不是持續同步的工作區。建立前檢查完整 thread，選對個人或工作區連結；建立後到 Data controls 管理連結，發現敏感內容就撤銷並輪替憑證。只要把它當成一份需要 review 的文件，而不是「自動遮罩後就安全」的視窗，這個功能才適合放進日常開發流程。

常見問題#