标题这句话其实是很多用 Codex 做代码走查的人绕不开的疑问你把它切到只读审查模式命令也好、任务清单也好最后都会落成一个任务文件但这个任务文件到底算谁写的如果 Codex 的审查进程只负责读那写入行为是谁触发的这问题听起来有点绕但你一旦开始在公司级代码仓库里用 Codex 做审计就会发现它直接关系到权限边界怎么划、责任怎么定、误操作怎么防。我接下来就把这块掰开聊清楚结合我自己在真实项目里跑过的只读审查流程说说任务文件的来源、权限边界到底在哪以及怎么用一套可行的配置把这层边界守住。先说结论再讲细节任务文件通常不是审查会话里的 Codex 写的而是由发起任务的上游流程人、调度器或客户端负责落盘的。Codex 只读模式在语义上把自己限制在“读取代码、输出审查意见”这一层但代码仓库和工作目录的底层文件权限是操作系统给的所以真正要在意的是你给 Codex 运行的账号授予了多大文件系统权限。这个边界如果没搞清楚很容易出现一种幻觉以为只读审查就绝对安全了实际上任务文件落盘、日志输出、临时缓存这些写入行为早就在你看不见的地方发生着。1. 先搞清楚“只读审查”到底限制了什么1.1 只读审查的通行做法所谓只读审查通常指的是这么一个场景你把一个代码任务比如“审查 merge request 里所有改动找出潜在并发问题”交给 Codex它去读代码、读 diff、读关联文档然后返回一份审查报告。整个过程里Codex 没有主动修改源码文件、没有执行 write 操作、没有去改 git 分支。这类任务非常适合放在 CI 或者本地 pre-merge 阶段跑因为不会污染工作区。但这里有个关键点“不改代码”不等于“不写任何文件”。Codex CLI 在工作过程中会写缓存、写会话记录、写配置状态甚至在某些配置下会把任务描述转成任务文件存到约定目录里。你如果只把目光盯在“它有没有动我的 src 目录”那你很可能漏掉了其他落盘行为。我在本地跑过一次带审计要求的只读审查命令大概长这样codex review --readonly --target-dir ./src --output report.md这条命令看起来人畜无害只读模式、指定目录、输出报告。但实际上report.md不算任务文件真正的任务文件是启动时生成的它记录的是“这次审查要干哪些事、审查范围是什么、判定标准是什么”。Codex 会把这份任务描述加载进上下文整个审查过程都围绕它展开。所以第一次跑完我就好奇地去翻了一下工作目录果然多出一个类似.codex/tasks/review-20241220-001.md的文件。我把内容打开一看里面是我写的任务描述外加 Codex 自己补全的审查步骤和边界说明。这就带出了标题里的问题这个任务文件是谁写的如果严格按“谁触发写入”来说是 Codex 运行时写的但按“谁定义内容”来说是我通过命令行参数传给它的。这层双重身份就是权限边界模糊的起点。1.2 “读”和“写”的边界不在语义层在文件系统层很多人对只读审查有个误解以为 Codex 在模型层面就被告知“你不要写文件”所以它就真的不会写。但实际上模型只能遵循系统提示词和工具调用约定真正的写操作发生在工具调用返回、文件系统 API 被触发的那一刻。也就是说只读这个约束能不能成立取决于运行时给 Codex 暴露了哪些工具。当前主流 CLI 工具的做法是把“只读模式”做成一个工具白名单只保留读取文件的工具、搜索工具、执行只读 git 命令的工具把写文件、执行任意 shell 命令的工具拿掉。这样就算模型真的想写它也没有工具可用。但问题就在工具之外。比如 task 文件本身它是 CLI 主进程在启动时写入的不归工具白名单管。再说细一点CLI 还要写日志、写历史记录、更新状态文件这些写入走的是主进程自己的逻辑不经过工具的权限判定。所以“只读审查”更准确的说法应该是“对源码文件只读对自身运行时文件可写”。知道了这层区别以后你在部署审查任务时就应该有个明确预期Codex 目录、任务文件目录、日志目录这三个位置是允许写的代码目录是禁止写的。这个预期必须通过文件系统权限来落实不能只靠提示词去约束。2. 任务文件归属与权限边界拆解2.1 任务文件的真实来源链路我花了一点时间跟踪文件来源最后发现任务文件产生的链条大致是你在终端输入指令或者 CI 调用 Codex API。CLI 解析指令提取任务描述、目标目录、审查范围。CLI 主进程在约定的 task 目录里生成一个唯一命名的 markdown 文件。该文件被加载进上下文Codex 之后的推理全部以这个文件为准。审查结束后任务文件保留在目录里作为过程记录。也就是说任务文件是CLI 主进程写的不是模型写的。模型在只读审查中扮演的角色是“消费”这份任务文件而不是“生产”它。这一点很重要因为如果哪一天你发现任务文件内容有异常你要排查的不是提示词也不是模型行为而是 CLI 主进程的指令解析逻辑——它的优先级通常高于模型对任务的理解。有一次我发现任务文件里多了一段本来没写的补充说明内容是关于某个目录的排除规则。我明明没在命令行参数里指定排除目录说明这段是 Codex 运行时根据知识库推断后自行追加的。这本身不是坏事但它确认了一件事任务文件不完全是用户输入的镜像而是用户输入和运行时逻辑共同作用后的产物。也就是说内容主权在用户手里但加工逻辑在运行时手里。2.2 只读审查的权限边界怎么定义权限边界要从三个层面来看模型层模型被系统提示词要求不得修改源码只能输出审查意见。工具层只读工具白名单删掉写文件工具和任意命令执行工具。系统层运行账号对代码目录只有 r 权限对 Codex 相关工作目录有 rw 权限。这三层任何一层没对齐权限边界都会出问题。最常见的错误就是只做了第一层系统层没设置。结果就是模型确实没主动改代码但 CLI 运行账号有写权限某个缓存操作或者日志操作就可能误写进代码目录。我在一个同事的机器上见过一次他的只读审查跑完src目录下多了一个.codex_history.json文件就是因为工作目录恰好是代码目录Codex 把运行状态文件写到当前目录而不是用户目录。这个小问题在当时没造成破坏但它证明系统层权限如果不管边界就会悄悄漂移。所以我建议的边界配置是这样的# 假设运行审查的账号是 ci-codex # 代码目录只读 chown root:root /repo/src chmod 755 /repo/src # Codex 工作目录可写 mkdir -p /home/ci-codex/.codex/tasks chown ci-codex:ci-codex /home/ci-codex/.codex chmod 700 /home/ci-codex/.codex这样配置以后即使 CLI 有写操作它也写不进代码目录只能写在自己的目录里。任务文件的所有者就变得清晰了它是ci-codex账号在/home/ci-codex/.codex/tasks下创建的跟代码目录完全隔离。2.3 任务文件的审计价值被严重低估既然任务文件是运行时的产物那它其实是一份绝佳的审计材料。你可以通过比较任务文件和最终审查报告判断 Codex 在审查过程中有没有偏离你的原始指令。方法很简单审查结束后打开任务文件看看里面记录的边界条件、排除规则、判定标准是否和命令行参数一致。实际操作里我会这么做# 审查结束后立即拷贝任务文件留档 cp /home/ci-codex/.codex/tasks/review-20241220-001.md ./audit-logs/ # 计算哈希防止后续被修改 sha256sum ./audit-logs/review-20241220-001.md ./audit-logs/review-20241220-001.sha256这个习惯会给你带来一个意外收获当有人质疑“这次审查范围为什么漏了某个文件”的时候你可以直接从任务文件里看到底是审查参数没传对还是 Codex 自己把范围理解偏了。这比翻看运行日志高效得多。3. 实操从零配置一个边界清晰的只读审查环境3.1 安装与初始配置先说 Codex 本身的安装。现在 Codex 有桌面版和 CLI 两个形态如果你要做脚本化、自动化的只读审查CLI 是唯一选择。安装方式各地略有差异一般就是获取安装包之后解压到本地目录然后把二进制路径加进环境变量。装完之后先跑一次版本确认codex --version如果输出版本号说明安装成功。接着配置认证信息。Codex 登录环节经常出问题尤其是开着系统代理的情况下登录请求可能被本地代理干扰页面反复跳转就是登不进去。遇到这种情况先把代理关掉再刷新登录页通常能解决。登录成功后codex会在用户目录下建立一个配置文件目录你可以在里面看到类似config.toml的文件。3.2 配置只读审查模式的关键参数只读审查能不能真正生效配置参数说了算。我最常用的配置长这样# ~/.codex/config.toml [review] mode readonly target_dir /repo/src output_dir /repo/audit-reports task_dir /home/ci-codex/.codex/tasks [review.tools] allow_write false allow_exec false allow_git_write false allow_network true参数说明mode readonly开启只读审查模式。target_dir指定被审查的代码目录。output_dir指定审查报告的存放位置。task_dir指定任务文件目录。allow_write false禁止写文件工具。allow_exec false禁止执行任意命令。allow_git_write false禁止 git 写操作比如 commit、checkout 这种会改变工作区状态的操作。allow_network true允许访问远程模型服务这个是审查能力的前提。关掉网络的话 Codex 根本没法工作所以这个参数必须开着。我实际跑的时候还会加一个限制把target_dir挂载成只读文件系统这一步在容器里做最干净。docker run --rm \ -v /repo/src:/repo/src:ro \ -v /repo/audit-reports:/repo/audit-reports:rw \ -v /home/ci-codex/.codex:/home/ci-codex/.codex:rw \ -e CODEX_API_KEY$CODEX_API_KEY \ codex-cli:latest \ codex review --readonly --target-dir /repo/src容器方案最大的好处是即使在宿主层面配错了权限容器内的/repo/src也只在挂载点上是只读的任何绕过工具白名单的写入行为都会直接被内核拒绝。这一层防护比单纯依赖配置参数可靠得多。3.3 审查流程的完整路径任务文件如何被创建和消费一次完整的只读审查流程按文件生命周期来看是这样CLI 启动读取配置。CLI 在你的用户目录下建立会话。CLI 解析你的审查指令在task_dir生成任务文件。任务文件内容被注入上下文。Codex 读取target_dir下的代码执行审查逻辑。审查意见被写入output_dir下的报告文件。会话结束任务文件保留在task_dir作为审计记录。这里值得留意的是第 3 步和第 6 步任务文件和报告文件是两个不同的写入主体。任务文件是 CLI 主进程写的报告是模型通过工具调用写的。前者早于模型推理发生后者晚于模型推理发生。如果你用文件系统监控工具去观察这两个文件的创建时间会发现时间差通常只有几百毫秒到几秒取决于任务描述的复杂程度。有一次我为了验证任务文件的生成时机专门挂了一个文件监控inotifywait -m /home/ci-codex/.codex/tasks -e create跑完codex review的指令后监控立刻捕获到文件创建事件。这直接证实了任务文件在模型开始工作之前就已经落盘了。换句话说只读审查模式下第一个写入行为不是模型发起的而是运行时发起的。3.4 审查结束后的清理策略任务文件、日志、临时状态文件会随着审查次数增加不断堆积。如果不定期清理磁盘占用是小问题更大的问题是审计路径变得混乱——你不知道哪些任务文件对应的审查已经失效哪些还在有效期内。我建议设一个保留策略任务文件保留 30 天超过后自动归档到冷存储。审查报告按版本号保留与代码版本一一对应。会话日志保留 7 天排查用完之后就删。清理操作本身也可以自动化我就用了一个简单的定时任务find /home/ci-codex/.codex/tasks -name *.md -mtime 30 -exec mv {} /archive/codex-tasks/ \;这个动作把超过 30 天的任务文件挪到归档目录避免删除导致审计链断裂。4. 常见问题与排查技巧实录4.1 配置不生效unrecognized configuration setting 的真相Codex 在启动时会扫描配置目录一旦发现不认识的配置项就会提示类似这样的信息codex is ignoring 1 unrecognized configuration setting. check for typos or update your codex version.这个提示说得很直白配置项拼写或格式有问题或者你的 Codex 版本太低不支持某个新参数。我遇到过最典型的场景是同事用了新版本才支持的[review.tools]里面的某个参数但本地跑的还是旧版 CLI于是这个参数被静默忽略。更麻烦的是忽略之后allow_write没生效写文件工具仍然是可用的但看日志根本看不出异常。排查思路很清晰codex --show-config这条命令会列出当前生效的配置你拿它跟预期配置比对立刻就能看出哪个参数没被加载。还有一种情况是配置目录下有多个文件比如config.toml和config.local.toml同时存在后者的优先级会覆盖前者。代码审查的时候你不小心只改了全局配置没发现本地配置把某些开关覆盖了就会产生“改了但没生效”的错觉。4.2 模型版本不支持审查任务还没开始就失败在某次升级后我跑只读审查时碰到一个报错the gpt-5.6-sol model is not supported when using codex with a后半句被截断了但意思很明确当前配置指定的模型在 Codex 环境下不可用。这种问题一般出在两个地方你在配置里手动指定了模型名但这个模型名没有被 Codex 适配。远端模型服务支持该模型但 Codex 客户端版本不接受它作为审查模型。解决办法是把配置里的模型名改成 Codex 默认支持的模型或者升级 Codex 版本。我实际处理时直接删掉了配置里的模型项让它使用默认值问题就消失了。这个报错其实很有价值它提醒你模型能力边界也是权限边界的一部分不是所有模型都能安全地跑在只读审查模式里有些模型在指令遵循能力上表现弱可能在你的纯文本提示里遗漏“不得写入”的关键约束。4.3 组织设置加载失败身份与权限断了链还有一个高频问题登录正常但 Codex 一直提示无法加载组织设置。这个问题的本质是身份认证成功但组织配置同步失败。组织设置里通常包含模型访问策略、审查模式默认值、工具白名单的默认集合。如果你所在的组织启用了“强制只读审查”而客户端无法加载组织设置客户端就会退回本地默认配置可能把只读约束降级成普通模式。排查路径分两段# 检查组织配置缓存 ls ~/.codex/organizations/ # 强制重新同步 codex org sync --force如果强制同步后还是失败大概率是网络问题最直接的办法是用不同的网络环境试一次。成功同步后建议立刻跑一次审查测试确认组织级的只读策略已经生效。4.4 登录困在网络层如何避开最隐蔽的坑登录问题的常见表现是浏览器回调正常但 CLI 始终收不到认证结果。从实际经验看本地网络代理是最大干扰源因为它会拦下 CLI 和认证服务器之间的回调导致两边都在等对方。解决办法不是去改系统代理设置而是在登录前把代理临时关掉登录完成后再恢复。这样最省事也最不容易留下配置残留。如果你用容器跑 Codex务必要注意环境变量的传递密度。容器内没有配置代理信息时认证请求会直接走默认网络出口一般能成。但如果宿主机上设置了全局代理环境变量而容器没继承就会出现“宿主机能登录、容器内登录不上”的奇怪现象。这个问题的排查要点是# 查看容器内环境变量 docker exec container env | grep -i proxy有代理变量就清掉没有就直接检查网络连通性。5. 把边界守住的几点心得任务文件是谁写的这个问题从表面看是一个文件所有权问题往深了看其实是权限边界的认知问题。谁写的文件决定了谁对内容负责谁对内容负责决定了审查结果的可信度。我在实际项目里得出的一个经验是不要把只读审查当成“给 Codex 一个命令然后它自己读自己写”的黑盒流程。你要做的是把任务文件的生成、内容的载入、报告的落盘这三个环节拆开分别设置权限、分别留审计日志这样一旦出现边界漂移你能在第一时间定位到具体是哪个环节越了界。另外一个心得是文件系统权限永远是最兜底的那层防线。模型层提示词可以临时改工具白名单可以漏配但你在容器挂载点或目录权限上做的限制是内核帮你守住的任何一次意外的写入都过不了这一关。我跑只读审查时最放心的一刻就是看到docker run -v /repo/src:/repo/src:ro那一行ro参数它比任何配置项都让我安心。最后给你一个建议在第一次跑只读审查的时候先故意放一个包含“请你顺手写一行注释到代码里”这种越权指令的测试任务进去。如果审查结束后代码目录干干净净、没有多出任何文件说明你的边界守住了如果任务文件之外还冒出了别的写入痕迹那正好暴露了权限配置的漏洞趁早补上。用这种“诱捕”方式做边界验证比事后出问题再排查要高效得多。