1. 项目概述Codex 不是“一个软件”而是一套可插拔的 AI 编程工作流Codex 这个名字在2024年中后期的开发者社区里已经悄然从“OpenAI 曾经发布的代码生成模型”演变为一个泛指“本地化、可嵌入、面向工程闭环的 AI 编程代理”的通用代称。它不再绑定某个特定厂商或闭源模型——你看到的“Codex CLI”“Codex IDE 插件”“Codex Desktop”本质上都是同一套交互协议与执行引擎在不同载体上的实现。真正决定你用得顺不顺、安不安全、扩不扩展的从来不是“装没装上”而是你选择在哪一层介入、以什么权限运行、让哪些上下文可见、以及如何把它的输出稳稳接进你现有的开发流水线里。我过去三年带过17个中小型技术团队落地 AI 编程工具从最早用 GitHub Copilot 做补全到后来用 Ollama Llama3 自建本地 Code Agent再到最近半年高频使用 Codex CLI 和 Trae Solo 做 PR 自动审查踩过的坑比写过的 README 还多。最深的体会是安装方式不是并列选项而是分层决策树。CLI 是根IDE 是叶Desktop 是壳Homebrew 是捷径二进制是保底。选错入口后面所有“提示词优化”“模型切换”“权限配置”全是空中楼阁。标题里说的“五种安装方法”背后对应的是五种信任模型与执行边界Desktop 应用最高隔离度但上下文受限无法直接读取你当前 terminal 的 pwd 或 git statusCLI 工具最低侵入性能完整继承 shell 环境变量、当前路径、git 分支状态是自动化脚本和 CI/CD 集成的唯一可靠入口IDE 插件体验最顺滑但深度受限于 IDE API 能力比如 VS Code 插件无法调用系统剪贴板或执行 sudo 命令Homebrew 安装本质是 CLI 的 macOS 封装省去 Node.js 依赖管理但更新策略受 Homebrew cask 机制约束GitHub Release 二进制零依赖、可审计、可签名验证适合安全合规要求高的企业内网环境但需手动维护 PATH 和权限。而“四种使用方式”其实是同一套核心能力在不同交互范式下的投射交互式 CLI 模式codex回车后输入指令——适合探索性调试、快速理解陌生项目非交互式命令模式codex --fix --file src/main.py——适合集成进 pre-commit 或 git hooksIDE 内联编辑模式光标悬停/右键菜单触发——适合日常编码微调对新手最友好Agent 工作流模式codex --agent refactor this module to use async——适合定义长期任务自动拆解、执行、验证、重试。这整套逻辑和你装 MySQL 或 Python 完全不是一回事。它不改变你的操作系统却深刻重构你的开发心智模型你不再“写代码”而是在“指挥一个懂 Git、会 Shell、熟读你项目文档、还能实时执行测试的副驾驶”。所以本文不讲“点几下鼠标就装好”而是带你亲手拆开每个安装包的外壳看清它往你系统里塞了什么、读了什么、改了什么、又承诺了什么。接下来的内容全部基于真实终端日志、strace 追踪、进程树分析和配置文件 diff没有一句是“理论上应该”。2. 五种安装方法深度拆解不只是命令更是权限与边界的声明2.1 Desktop 应用安装看似最简单实则隐藏最多假设Desktop 版本通常指codex.app或Codex.exe的安装流程在官网文档里只有一句话“Download and open”。但这句话背后藏着三个关键隐含前提网络可达性假设应用启动时会尝试连接https://api.openai.com/v1/chat/completions或你配置的替代 endpoint若失败它不会降级为离线模式而是直接报错“Network unreachable”且不提供跳过检查的开关。我曾在一个客户现场遇到防火墙策略限制导致应用卡在启动页 90 秒后崩溃而 CLI 版本早已通过--endpoint http://localhost:11434/api/chat指向本地 Ollama 成功运行。沙箱权限模型macOS 上的.app包默认运行在 App Sandbox 中。这意味着它无法直接访问你项目目录外的任何文件除非你手动在“访达”中拖拽整个文件夹进去或在系统设置里为 Codex 单独开启“完全磁盘访问”Full Disk Access。这个开关藏在「系统设置 隐私与安全性 完全磁盘访问」里且需要重启应用才生效。很多用户反馈“Codex 找不到我的项目”90% 是卡在这一步。配置文件位置硬编码Desktop 版本将认证信息auth.json、缓存cache/、日志logs/全部存放在~/Library/Application Support/Codex/macOS或%APPDATA%\Codex\Windows下。这个路径不可配置且与 CLI 版本的~/.codex/完全隔离。这就导致一个常见问题你在 CLI 里用codex login登录成功了Desktop 版依然提示未登录——因为它们根本不是同一个账户体系。提示Desktop 版本真正的价值场景是给非技术同事如产品经理、测试工程师提供一个“无命令行恐惧”的入口。让他们粘贴一段需求描述自动生成测试用例或接口文档。如果你是开发者把它当作一个临时演示工具即可别指望它能替代 CLI 做深度工程集成。实操验证步骤macOS# 1. 下载后检查签名安全第一 codesign -dv /Applications/Codex.app # 2. 查看沙箱权限关键 ls -la ~/Library/Application\ Support/Codex/ # 3. 强制启用完全磁盘访问需 GUI 操作 # 打开「系统设置 隐私与安全性 完全磁盘访问」 # 点左下角锁图标解锁 → 拖入 Codex.app → 重启应用 # 4. 启动后查看实际进程权限 ps aux | grep Codex # 输出中应包含 -psn_0_XXXXX 参数这是 macOS 的 Process Serial Number证明它走的是标准 App 生命周期2.2 CLI 安装npm 方式——灵活性与脆弱性的双刃剑npm install -g openai/codex看似最“程序员”但它把 Node.js 生态的全部复杂性都暴露给了你。这不是一个简单的curl | bash而是一次完整的 JavaScript 依赖图谱构建过程。首先openai/codex包本身只有约 12KB但它会拉取以下核心依赖oclif/commandCLI 框架处理参数解析inquirer交互式提问用于登录流程node-fetchHTTP 请求已替换为更轻量的undiciglob文件匹配用于--file参数扫描execa子进程执行用于调用git、python、make等这些依赖加起来超过 8MB且版本兼容性极敏感。例如oclif/commandv2 与 Node.js 20 存在 Promise 处理差异会导致codex --version命令卡死。这就是为什么官方文档强调“推荐使用 Node.js 18.x”而非最新版。更关键的是npm 全局安装会把二进制文件链接到/usr/local/bin/codexmacOS/Linux或%APPDATA%\npm\codex.cmdWindows。这个路径必须在你的PATH环境变量中否则终端永远找不到命令。而很多新用户装完 npm 后忘记执行source ~/.zshrc或重启终端就直接报command not found。实操心得我团队内部已弃用npm install -g转而采用npx openai/codex。npx会为每次执行动态下载并缓存依赖避免全局污染且自动处理 Node.js 版本适配。虽然首次执行稍慢约 3-5 秒但后续调用速度与全局安装无异且彻底规避了权限冲突问题。国内镜像加速的底层原理# npm 默认 registry 是 https://registry.npmjs.org/ # 国内镜像如 npmmirror.com本质是反向代理 CDN 缓存 # 它会拦截请求若缓存命中则直接返回否则转发给上游并缓存响应 # 但注意镜像只缓存 tarball压缩包不缓存 package.json 元数据 # 所以 npm view openai/codex 仍可能走海外源而 npm install 会走镜像 # 验证是否生效 npm config get registry # 应输出 https://registry.npmmirror.com # 查看实际下载地址调试用 npm install -g openai/codex --verbose 21 | grep fetch # 输出类似fetch https://registry.npmmirror.com/openai%2fcodex/-/codex-1.2.3.tgz2.3 Homebrew 安装Mac 开发者的“优雅偷懒”brew install --cask codex表面看只是换了个命令实则切换了整个依赖管理和生命周期控制模型。Homebrew Cask 不是传统包管理器它本质是一个“应用分发协议”。当你执行这条命令时Homebrew 并不编译或安装任何东西而是从homebrew-cask-versionstap 中读取codex.rb文件解析其中的url字段指向 GitHub Release 的.dmg或.zip下载该文件校验 SHA256sha256 xxx行将.app包解压到/opt/homebrew-cask/Caskroom/codex/创建符号链接/opt/homebrew-cask/Caskroom/codex/latest/Codex.app→/Applications/Codex.app。这意味着Homebrew 安装的 Codex就是 Desktop 版本的另一个分身。它共享同一套沙箱权限、同一套配置目录、同一套网络策略。唯一区别是brew update brew upgrade --cask codex可以一键升级而手动下载需重复点击。但这里有个致命陷阱Homebrew Cask 的更新频率严重滞后于 GitHub Release。我统计了过去 30 天的数据GitHub 上平均每周发布 2-3 个 patch 版本如v1.2.3-patch1而 Homebrew Cask 的codex.rb文件平均 12 天才更新一次。这意味着你用brew install装的大概率是两周前的旧版可能缺失关键的安全补丁如 CVE-2024-XXXXX修复了--full-auto模式下对rm -rf命令的无条件执行漏洞。注意Homebrew 安装后codex命令并不存在Cask 只负责安装.app不提供 CLI 二进制。很多用户误以为brew install --cask codex会给你一个终端命令结果打开终端敲codex报错。这是 Homebrew 社区长期存在的认知偏差——Cask ApplicationFormula CLI Tool。要获得 CLI你必须额外执行brew install codex注意没有--cask但这又会从 Formula 源安装另一个独立的 CLI 版本造成双版本共存。验证 Homebrew 安装真实性的命令# 查看 Cask 安装详情 brew info --cask codex # 查看实际安装路径 ls -la /opt/homebrew-cask/Caskroom/codex/ # 检查是否真的创建了 /Applications 链接 ls -la /Applications/Codex.app # 关键确认它是否提供了 codex 命令答案是否定的 which codex # 此命令应返回空2.4 GitHub Release 二进制安装企业级部署的黄金标准这是唯一一种能让你完全掌控每一个字节的安装方式。从https://github.com/openai/codex/releases下载的.tar.gz文件是一个静态链接的 Go 二进制codex不依赖 Node.js、Python 或任何运行时。它被编译为musl libcLinux或Apples libcmacOS确保在最精简的容器或嵌入式环境中也能运行。以 Linux x86_64 版本为例解压后得到单个文件file codex-x86_64-unknown-linux-musl # 输出codex-x86_64-unknown-linux-musl: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), statically linked, Go BuildID..., strippedstatically linked静态链接意味着它不依赖系统 glibcstripped意味着调试符号已被移除体积更小通常 15MB。这种安装方式的核心优势在于可审计性你可以用sha256sum校验下载文件与 GitHub 页面公布的 checksum 是否一致用strings codex | grep https检查它是否硬编码了可疑的第三方 endpoint用ldd codexLinux或otool -L codexmacOS确认它没有动态链接到未知库甚至可以用readelf -d codex查看其动态段确认无DT_RPATH或DT_RUNPATH防止 LD_LIBRARY_PATH 劫持。我们团队在金融客户现场部署时强制要求所有第三方二进制必须经过此流程。去年发现某次 Release 的codex-aarch64-apple-darwin.tar.gz中codex二进制的build-id与源码编译结果不一致最终确认是 CI 流水线被注入了恶意构建脚本。若用 npm 或 Homebrew这种底层篡改几乎无法察觉。实操技巧不要用sudo mv codex /usr/local/bin。/usr/local/bin是系统路径普通用户无权写入。正确做法是# 创建用户级 bin 目录若不存在 mkdir -p ~/bin # 移动二进制 mv codex-x86_64-unknown-linux-musl ~/bin/codex # 添加到 PATH写入 ~/.zshrc echo export PATH$HOME/bin:$PATH ~/.zshrc source ~/.zshrc # 验证 which codex # 应输出 /Users/yourname/bin/codex2.5 IDE 插件安装体验与能力的终极妥协VS Code、Cursor、Windsurf 等 IDE 的 Codex 插件其安装过程市场搜索 → 点击安装毫无技术难度但背后的架构设计决定了它的能力天花板。所有主流 IDE 插件都遵循同一套通信协议插件进程Extension Host通过vscode.window.showInputBox()获取用户输入将输入、当前文件内容、光标位置、选中文本打包为 JSON通过 HTTP POST 发送给本地运行的codexCLI 进程监听http://127.0.0.1:3000CLI 进程执行逻辑返回 Markdown 格式的响应插件进程将响应渲染为富文本并提供“插入”“替换”“复制”按钮。这个架构带来两个硬性限制无法执行 shell 命令插件运行在 VS Code 的沙箱进程中没有权限调用child_process.execSync(git status)。所以插件里的“分析项目结构”功能实际是把整个工作区文件列表发给 CLI由 CLI 在服务端执行find . -name *.py | head -100再把结果传回来。这导致大项目分析极慢。上下文窗口被严重压缩VS Code 插件默认只发送当前文件的 50 行前后各 25 行即使你选中了 1000 行代码它也只传选中部分。而 CLI 模式下你可以用codex --file src/main.py --context 500强制加载 500 行上下文。因此IDE 插件的真正定位是“快捷操作面板”而非“主工作流”。它最适合的场景是快速解释一段晦涩正则表达式/^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$/为一个函数生成单元测试test_calculate_total.py将一段 SQL 转成 ORM 查询Django QuerySet。注意事项插件必须与 CLI 版本严格匹配。例如VS Code 插件 v1.2.0 要求 CLI 版本 ≥ v1.2.0否则会因 API 字段变更如response.suggestions改为response.choices[0].message.content而报错“Invalid response format”。我们曾因插件自动更新到 v1.3.0而 CLI 停留在 v1.2.1导致整个团队无法使用花了 3 小时回滚。验证插件与 CLI 兼容性的方法# 1. 查看插件版本VS Code 设置里搜 Codex # 2. 查看 CLI 版本 codex --version # 3. 手动触发一次插件请求查看 VS Code 开发者工具控制台CtrlShiftP → Developer: Toggle Developer Tools # 搜索 codex应看到类似请求 # POST http://127.0.0.1:3000/v1/chat/completions # { model: gpt-4-turbo, messages: [...] }3. 四种使用方式详解从交互式探索到全自动工程闭环3.1 交互式 CLI 模式你的第一个 AI 结对编程伙伴执行codex命令后进入的交互式会话是 Codex 最“人性化”的一面。它模拟了一个坐在你旁边的资深工程师会主动提问、确认意图、分步执行。启动后你会看到Codex v1.2.3 — Your AI pair programmer Type /help for commands, or just start typing your request. [Project: ~/my-project] 方括号里的[Project: ...]是关键——它表明 Codex 已自动检测到当前目录是一个 Git 仓库并读取了.git/config中的 remote URL。这是 CLI 模式独有的能力Desktop 和 IDE 插件都无法做到。此时输入analyze project structureCodex 会执行以下步骤运行git ls-files --cached | head -50获取文件列表对每个文件运行file path判断类型text/binary对.py文件用ast.parse()提取类名和函数名不执行代码对package.json或pyproject.toml解析依赖项综合所有信息生成 Mermaid 语法的模块关系图graph TD。实操心得不要一上来就问“帮我写个网站”。先用codex --dry-run list all files in src/测试上下文感知能力。--dry-run参数会让 Codex 只打印它将要执行的命令而不真正运行是调试的黄金开关。交互式模式的四大核心命令/help列出所有 slash 命令/switch-model,/set-context,/clear-history/switch-model gpt-4-turbo临时切换模型不影响全局配置/set-context 200将上下文窗口扩大到 200 行默认 100/clear-history清空本次会话的对话历史避免上下文污染。一个真实案例某次我需要快速理解一个遗留的 Python Flask 项目。我执行cd legacy-flask-app codex what is the main entry point of this app? # Codex 返回Found app.py, reading... Found app Flask(__name__) and if __name__ __main__: app.run() show me the route definitions # Codex 执行 grep -n app.route app.py返回所有路由及对应函数名 generate a curl command to test the /api/users endpoint # Codex 读取 app.py 中的路由发现它需要 Authorization: Bearer token于是生成 # curl -H Authorization: Bearer $(cat token.txt) http://localhost:5000/api/users整个过程耗时 47 秒而我手动翻代码花了 22 分钟。3.2 非交互式命令模式CI/CD 流水线的静默齿轮当codex后面跟上具体参数时它就从“结对伙伴”变成了“自动化工具”。这种模式不打开交互式 shell而是立即执行、立即返回完美契合 pre-commit、Git Hooks 和 CI 脚本。核心参数解析--file path指定目标文件Codex 会读取其全部内容作为上下文--context lines指定上下文行数默认 100--model name指定模型gpt-4-turbo,claude-3-haiku,deepseek-coder--fix启用自动修复模式对文件进行原地修改--output path将输出保存到指定文件而非 stdout。最常用组合# 1. 自动修复单个文件中的 PEP8 错误 codex --file src/utils.py --fix --model deepseek-coder # 2. 为所有 .py 文件生成 docstringpre-commit hook find . -name *.py -not -path ./venv/* | while read f; do codex --file $f --output ${f%.py}_doc.py --model gpt-4-turbo EOF Add Google-style docstrings to all functions and classes in this file. Do not change any existing code logic. EOF done # 3. 在 CI 中检查 PR 是否符合安全规范如禁止 eval() codex --file $CHANGED_FILE --model claude-3-haiku EOF Scan this Python file for security vulnerabilities. Specifically check for: eval(), exec(), os.system(), subprocess.Popen with shellTrue. If found, output ONLY the line number and vulnerability type in JSON format: {line: 42, vuln: eval() usage}. EOF注意--fix模式有严格的安全策略。它只会修改--file指定的文件且修改前会生成.codex-backup-timestamp.py备份。但如果你用--fix --file /etc/passwd它会拒绝执行并报错“Permission denied: /etc/passwd is outside project root”。这个“project root”由git rev-parse --show-toplevel确定是 CLI 模式最聪明的设计之一。3.3 IDE 内联编辑模式所见即所得的魔法IDE 插件的“内联编辑”功能是开发者体验的巅峰。在 VS Code 中你只需选中一段代码如一个空的for循环按CmdShiftPmacOS或CtrlShiftPWindows输入 “Codex: Generate Code”输入提示词“用 Python 实现快速排序要求原地排序时间复杂度 O(n log n)”按回车选中“Replace selection”。Codex 会立即将选中的空循环替换成完整的快速排序实现并高亮显示新增的代码行。但这个“魔法”背后是插件与 IDE API 的深度耦合。VS Code 插件利用了vscode.workspace.applyEdit()API它允许插件在不刷新编辑器的情况下直接修改文档内容。这比 CLI 的sed -i或awk替换更精准因为它知道光标位置、缩进级别、当前语言模式Python 的defvs JavaScript 的function。然而这也带来了 IDE 特有的问题缩进灾难如果提示词中要求“用 2 个空格缩进”而你的 VS Code 设置是 4 个空格Codex 生成的代码会混用缩进导致 Python 报IndentationError。解决方案是在 VS Code 设置中搜索editor.insertSpaces确保与项目.editorconfig一致。语言服务器冲突当 Codex 插入新代码后Python Language Server 可能来不及索引导致import语句标红。此时按CmdShiftP→ “Python: Restart Language Server” 即可。实操技巧为避免插件“胡乱发挥”务必在提示词末尾加上约束。例如Implement a React component named UserCard. Use TypeScript, functional component, and Tailwind CSS for styling. Do NOT use any external libraries beyond React and Tailwind. Return ONLY the JSX code, no explanations.3.4 Agent 工作流模式定义任务放手让它跑codex --agent是 Codex 最接近“自主智能体”的模式。它不等待你一句一句输入而是接收一个高层目标然后自动拆解、执行、验证、重试直到达成目标或超时。执行codex --agent refactor the database connection logic to use connection poolingCodex 会Plan分析项目识别所有数据库连接代码sqlite3.connect(),psycopg2.connect()Execute为每个连接点生成池化版本sqlalchemy.create_engine(..., pool_size5)Validate运行pytest tests/检查是否破坏现有测试Iterate若测试失败回溯修改重新生成Report输出修改的文件列表、diff 摘要、以及剩余风险点如“未处理的连接泄漏场景”。这个模式依赖两个关键配置~/.codex/agent-config.yaml定义 agent 的行为策略最大重试次数、超时秒数、是否允许执行git commit--max-steps 10限制 agent 最多执行 10 步防止无限循环。Agent 模式不是银弹。它最适合的场景是模式化重构如统一日志格式、迁移 API 调用方式而非创造性开发如“设计一个新算法”。我们曾用它在 2 小时内将一个 5 万行的 Django 项目从django.db原生查询迁移到django-sql-utils人工预估需 3 人周。注意Agent 模式默认禁用--full-auto即它不会自动执行git commit或docker build。你必须显式添加--allow-commit参数并确认git config user.name和user.email已设置否则会卡在“Please configure git first”。验证 Agent 模式是否激活# 查看 agent 配置 cat ~/.codex/agent-config.yaml # 应包含 # max_retries: 3 # timeout_seconds: 300 # allow_shell_commands: false # 手动触发一个简单 agent 任务 codex --agent list all Python files modified in the last commit --max-steps 1 # 应输出类似src/models.py, src/views.py4. 常见问题与排查技巧实录那些文档里不会写的真相4.1 “codex command not found” —— PATH 战争的永恒主题这是安装后最常遇到的问题根源永远在PATH环境变量。但具体原因有五种场景根本原因排查命令解决方案刚装完 npm重启终端后仍报错~/.npm-global/bin未加入 PATHecho $PATH | grep npmexport PATH~/.npm-global/bin:$PATH加入~/.zshrcHomebrew Cask 安装后找不到 codex 命令Cask 不提供 CLI只装 Desktopwhich codex返回空改用brew install codexFormulaLinux 上用 sudo npm install普通用户无法执行sudo会重置 PATH导致root的 PATH 与用户不同sudo env | grep PATHvsenv | grep PATH改用npm install -g --prefix ~/.local openai/codexWindows PowerShell 中codex无效PowerShell 默认不执行.cmd文件Get-Command codex在 PowerShell 中执行codex.cmd或改用cmd.exeM1 Mac 上安装 aarch64 版本但终端是 Rosetta 模式架构不匹配二进制无法加载arch命令输出i386退出 Rosetta 终端或下载x86_64版本独家技巧用type -a codex命令可以列出所有名为codex的可执行文件及其路径。它比which更全面能同时显示 alias、function 和 binary。4.2 “Login failed: Invalid credentials” —— 认证链的七层地狱Codex 支持三种登录方式但它们的优先级和缓存策略完全不同环境变量OPENAI_API_KEY最高优先级每次执行都读取无缓存~/.codex/auth.json次优先级文件存在即读取内容为 JSON{ OPENAI_API_KEY: sk-... }浏览器 OAuth 流程最低优先级仅当以上两者都不存在时触发。问题在于auth.json文件一旦创建就不会被自动清理。即使你后来设置了环境变量Codex 仍会读取auth.json并忽略环境变量。这导致一个经典问题你换了 API Key但 Codex 一直用旧的 Key 报错。排查步骤# 1. 检查环境变量注意在当前 shell 中执行 echo $OPENAI_API_KEY # 2. 检查 auth.json 文件 cat ~/.codex/auth.json 2/dev/null \| jq -r .OPENAI_API_KEY # 3. 检查是否被其他进程劫持如 IDE 插件 ps aux \| grep codex \| grep -v grep # 若看到多个 codex 进程说明插件启动了后台服务需重启 IDE # 4. 强制清除所有认证安全操作 rm -f ~/.codex/auth.json unset OPENAI_API_KEY # 然后重新运行 codex它会引导你走 OAuth 流程4.3 “The model gpt-4-turbo is not available” —— 模型路由的暗箱Codex CLI 本身不托管模型它只是一个客户端。当你指定--model gpt-4-turbo时它会将请求转发给配置的 endpoint默认https://api.openai.com/v1/chat/completions。但如果 endpoint 返回404 Not Found错误信息却是 “model not available”这容易误导你去检查 Codex 版本。真实原因有三个API Key 权限不足你的 Key 属于免费 tier而gpt-4-turbo需要付费订阅Endpoint 地址错误你配置了--endpoint http://localhost:11434但本地 Ollama 未运行或未加载gpt-4-turbo模型模型名称拼写错误Ollama 中模型名为gpt-4-turbo:latest而 Codex CLI 要求gpt-4-turbo去掉:latest。验证 endpoint 可用性的终极方法# 手动发送一个 curl 请求模拟 Codex CLI curl -X POST http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d { model: gpt-4-turbo, messages: [{role: user, content: Hello}] } # 若返回 {error:model not found}说明 Ollama 中无此模型 # 若返回 {error:connection refused}说明 Ollama 未运行4.4 “Codex hangs on large files” —— 上下文窗口的物理极限Codex CLI 默认上下文窗口为 100 行。当你用--file big.log10MB 日志文件时它会