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
