Codex 凌晨更新，將屏幕內容「放進記憶」

PRODUCT

凌晨，OpenAI 為 Codex 上線了新功能「Chronicle」，讓 Codex 能根據屏幕內容工作

Codex 多了個記憶來源：你的屏幕

從此，你再跟 Codex 說話的時候，不用反復解釋「這個」「那個」指的是什么。它知道你現在在看什么，剛才什么報錯，兩周前在做什么項目

Chronicle 是上周 memories 預覽之上的擴展。memories 的來源是對話歷史，Chronicle 加的是屏幕上下文那一層

目前只對 macOS 上的 ChatGPT Pro 用戶開放，歐盟、英國、瑞士暫不支持，狀態是 opt-in research preview

場景一，直接看屏幕 debug

官方視頻里三個演示，第一個叫 Use what’s on screen

屏幕左邊是一段 CI 失敗日志。用戶打開 Codex 只問了一句：why is this failing?

Codex 沒要用戶貼報錯，也沒問是哪個 repo。它通過 Chronicle 抓到屏幕上的上下文，花了 1 分 43 秒自己查完

Codex 看了屏幕上的 CI 日志，自己定位到了具體的 job、文件和行號

最后定位到 GitHub Actions 的 build-preview job，具體在 src/pages/preview-build-fixture.astro 第 2 行：

astro

const articleCount: string = 404;

結論是 TS2322 類型錯誤，404 是 number 卻被聲明成了 string。Codex 還注意到，PR 標題里寫著 exercise CI failure handling，這是故意塞的類型錯誤 fixture

回答的底部標出了 1 memory citation，用了 MEMORY.md 第 2122 行的 repo-specific validation loop context 作為本地復現之前的參考

官方也配了一張關 Chronicle 的對比截圖。同樣這句 why is this failing，Codex 會直接說 I do not know what this refers to yet：

關掉 Chronicle 時，Codex 會反問你要具體的報錯文本或鏈接

場景二，屏幕上下文補全 this / that

第二個場景叫 Fill in missing context

用戶輸入：Sync with the latest docs draft changes and message Romain

latest docs draft 是哪份、Romain 是誰，用戶都沒說

Codex 通過 Chronicle memory 解析出是哪份草稿、哪個 Romain，然后同步文件再發 Slack

Codex 通過 Chronicle 找到了用戶在改的文檔草稿，同步了 chronicle.mdx，再調用 Slack skill 給 Romain 發了私信，告訴他同步狀態和 build 結果

如果細看過程，你會發現 GPT 在從 Chronicle 里思考 Roman 是誰，然后 memory 解析的內部推理寫得更明確：Memory points to the Google Doc Chronicle docs draft and Romain Huet on Slack

Chronicle 的 memory 里記著最近那份 draft 和 Romain Huet 的 Slack ID

整個過程里，this、that、latest 這幾個詞，用戶都沒說清，Codex 自己補上了

場景三，記住你常用的工具和流程

第三個場景叫 Remember tools and workflows

用戶說：Create an empty draft doc for the Chronicle launch copy to share with the team

Codex 在 memory 里查到用戶習慣用 Google Drive 做草稿，直接創建了 Google Doc

Codex 先查了 memory，確認用戶習慣把草稿放 Google Drive，然后直接調用 Google Drive tool 創建了 Chronicle Launch Copy [DRAFT] 這個文件。過程中彈出了權限確認對話框

關 Chronicle 的對比版本里，Codex 會反問你想要什么格式：What format should this be? I can draft it here, create a Google Doc, or prepare a Slack post

沒有 Chronicle 的 memory，Codex 不知道 launch comms 該放哪里

OpenAI 自己的解釋是：Codex 先用 Chronicle 定位源頭，真要干活的時候，再去讀具體的文件、Slack thread、Google Doc、dashboard 或者 PR

怎么啟用

除了開頭說的 Pro 加 macOS 限制，還要授予 Screen Recording 和 Accessibility 權限

啟用路徑：

01 打開 Codex 的 Settings

02 進入 Personalization，確認 Memories 已開

03 打開 Memories 下方的 Chronicle

04 點擊確認對話框的 Continue

05 macOS 彈權限申請時，授予 Screen Recording 和 Accessibility

菜單欄圖標里可以隨時 Pause 或 Resume。開會前、看敏感內容前先暫停

技術細節

屏幕截圖存在 $TMPDIR/chronicle/screen_recording/，6 小時后 Chronicle 自己刪掉

生成的 memory 存在 $CODEX_HOME/memories_extensions/chronicle/，默認就是 ~/.codex/memories_extensions/chronicle/

memory 本體是未加密的 markdown 文件，用戶可以讀、可以改、可以刪。OpenAI 建議不要手動加新條目，但局部改和刪是支持的

生成 memory 用的模型，默認跟 Codex 用的模型一致。想換別的可以在 config.toml 里設：

toml

[memories]

consolidation_model = "gpt-5.4-mini"

Codex 不會馬上生成 memory，會跳過活躍會話，過濾掉密鑰一類的敏感信息，等 thread 空閑一段時間再在后臺寫

風險和代價

官方文檔列了三個風險

一，rate limits。Chronicle 后臺跑 sandboxed agent 持續消耗額度，OpenAI 的原話是 uses rate limits quickly

二，prompt injection。屏幕上如果出現帶惡意 agent 指令的網頁，Codex 可能會按屏幕上的指令做

三，數據可見性。memory 文件未加密，同一臺電腦上的其他 app 也能讀到這些文件

麥克風和系統音頻 Chronicle 不拿，只拿屏幕截圖。OpenAI 特別提醒，別用 Chronicle 在沒獲得他人同意的情況下錄會議

Chronicle 拿去生成 memory 的時候，選中的屏幕截圖、OCR 出的文本、時間戳、本地文件路徑會一起傳到 OpenAI 服務器處理。處理完成后，截圖不保留，也不用于訓練

為什么今天只是 research preview

官方博客說，going forward, OpenAI is developing Codex into a more capable tool for builders beyond software engineers, and Chronicle is one step toward that goal

官方 X 的原話是：while we learn where it helps most and improve the experience

所以今天這一版是 opt-in 的，想試的 Pro 用戶自己去 Settings 里開

參考材料

→ Chronicle 官方文檔：developers.openai.com/codex/memories/chronicle

→ Memories 官方文檔：developers.openai.com/codex/memories

→ Codex 官方博客：openai.com/index/codex-for-almost-everything

→ OpenAI Developers X：x.com/OpenAIDevs

點個“愛心”，再走 吧