看到 OpenAI 新发的《Custom Code Review rules for Codex》时，我一开始以为它讲的是 GitHub PR 里的 @codex review。实际试着梳理文档后才发现，Codex 里至少有三种容易混在一起的代码审查入口：交互式 /review、非交互式 codex review，以及 GitHub PR 中的云端审查。 它们都叫 Code Review，但运行位置、输入范围和输出去向并不相同。AGENTS.md 又在其中增加了一层：除了告诉 Codex 怎样写代码，现在也可以告诉它审查时要特别留意什么。
两家公司给自己的 AI Agent 分别推出了 Chrome 扩展。表面上都是"让 AI 能操作浏览器"，但出发点几乎相反：Claude in Chrome 是把 AI 嵌进浏览器里，Codex Chrome 扩展是把浏览器接进 AI 任务系统里。 产品定位 Claude in Chrome 是 claude.ai 的浏览器扩展，主要形态是侧边栏。浏览时 Claude 在旁边响应，可以读当前页面、执行操作、或者后台跑多步骤工作流。也对接了 Claude Desktop，可以在桌面端控制浏览器。
Codex Security Plugin不是一个独立的安全工具，而是以插件形式嵌入到 Codex 工作流中的漏洞扫描系统。这篇文章整理一下它的工作原理、扫描流程和 CI/CD 集成方案，也对比一下它和传统静态分析工具的思路差异。 背景：为什么是插件而不是独立工具 传统的代码安全扫描（SAST）工具，比如 Semgrep、CodeQL、SonarQube，走的是规则匹配的路子：维护一套漏洞特征规则库，扫描代码时对模式进行匹配，找出潜在问题。这类工具的优点是确定性强、速度快、可以自动化集成。缺点也很明显——规则库覆盖不到的变种绕过不了，误报率偏高，而且几乎没有对业务逻辑的理解能力。
Codex 的远程连接不是一个功能，而是两套相互独立的方案，分别服务于 Desktop App 和 CLI，适用场景和限制也完全不同。 两套方案概览 主机端 客户端 传输协议 Remote Connections Codex Desktop App ChatGPT 手机 App 专有协议 Remote TUI Codex CLI（app-server） 另一台机器的 Codex CLI WebSocket 两者之间没有交集：手机 App 只能连 Desktop App，另一台 CLI 只能连 CLI 的 app-server，不能混用。
Codex 已经不只是一个待在终端和编辑器里的编程助手了。它现在可以通过不同的 surface 接触外部环境。这里的 surface 可以理解为 Codex 操作电脑和网页的入口，目前最容易混在一起的三种是：@Computer、@Chrome 和 @Browser。 它们看起来都和“用电脑”“打开浏览器”有关，实际边界却差得很远。选错入口，体验会立刻变差：需要登录态的后台任务，如果交给隔离的内置 Browser，它拿不到你的账号、Cookie 和浏览器扩展；只是看一个本地 localhost 页面，如果让 Computer Use 去打开真实浏览器一步步操作，就会把简单的页面验证变成慢点要死的慢动作。
Codex 的沙箱配置是 sandbox = workspace-write、approval = on-request，改仓库里的普通文件也一直弹 approve。启动时还有这条报错： Codex's Linux sandbox uses bubblewrap and needs access to create user namespaces 排查过程 先看基础条件：
这篇笔记整理自 OpenAI 开发者博客 Run long horizon tasks with Codex。原文记录了用 Codex 从零构建一个设计工具的完整实验，核心内容是如何让 AI 编程代理在长时间任务中保持连贯。 背景 GPT-5-Codex（2025年9月）是第一个针对代理式编程优化的 GPT-5 版本，12月发布的 5.2 开始让人觉得自主式编程代理可以变得可靠。
Codex 在 v0.98.0 之后默认开启了 Steer Mode。这个功能名字听着玄乎（Steer = 驾驶、掌舵），其实就是让你控制消息是“立即发”还是“先排队”。 以前的任务调度比较死，现在通过 Enter 和 Tab 两个键就能把控节奏。 Enter vs Tab 1. 按 Enter：立即提交 这就是最常用的提交方式，不管 AI 有没有在干活，按了就发。