近两年来“AI写代码”已经从概念变成了很多开发者的日常工作流而Codex就是这波变化里关注度极高的一款终端工具。它由OpenAI团队维护提供了一个本地命令行环境让AI可以直接读取项目文件、运行命令、修改代码而不是像网页聊天那样只给一段代码建议、再让人手动去粘贴。对于平时习惯用VS Code、终端或者SSH远程开发的人Codex更像一个住进终端里的编程搭档。这篇文章我会按当前最新版本环境从下载、安装、登录、配置到跑通第一个任务整理出一份能跟着一步步操作的手把手流程哪怕你之前只会在浏览器里用AI看完之后也能把本地版Codex支棱起来。1. Codex是什么下载前先搞清楚的事1.1 从“代码补全”到“终端里的开发搭档”很多朋友第一次听到Codex会以为它是某个老模型的名字这个理解不算错但也不完整。早几年确实有过一个叫Codex的模型擅长把自然语言转成代码片段而现在的Codex是一个完全不同的东西——它是官方发布的终端工具底层接入了新一代大模型同时把文件读取、命令行执行、代码修改这些能力都打通了。你可以把它理解成“一个住在终端里的AI开发助理”。它和网页版聊天工具的核心区别在于上下文和权限。网页版对话里AI只能看到你手动复制进去的代码片段而Codex在你本地的项目目录里启动后能直接扫描目录结构、读取文件内容、建立索引然后基于项目真实状态去改代码、执行测试、运行脚本。你不再需要反复复制粘贴上下文只要把任务描述清楚它就自己去看代码仓库里的情况。1.2 它具体能帮你做什么我实际用下来Codex最顺手的几个场景是新项目起步在空目录里让它生成一个完整的脚手架比如“用Python写一个带命令行参数的批量文件重命名工具”它会直接创建文件、装依赖、给出运行说明。修bug把当前报错贴给它它能顺着调用链找到可疑代码改完还能跑一遍测试确认。批量重构比如把项目里所有旧的日志写法替换成统一的日志组件这种重复但有风险的活交给它做比手工改安全得多。写一次性脚本临时处理Excel表格、批量压图片、拉取某个接口数据并整理成JSON这类脚本我不想留着直接让它生成并执行完事就删。它就像一个对代码库“有记忆”的助手前提是你给了它正确的任务边界和执行权限。1.3 别把Codex当“魔法棒”当然它也有不合适的地方。如果你希望它一次就生成一个几千行、零缺陷的商业系统那大概率会失望如果项目里有大量历史遗留的复杂业务逻辑、极难搜索的隐性规则它也可能给出表面合理但实际有问题的方案。更要紧的是它会执行终端命令所以遇到它主动提“要不要删文件”“要不要执行某个命令”的时候务必看清楚再确认。我的原则是它负责“写”和“改”我负责“审”和“放行”。2. 安装前的环境自查三件事最容易翻车2.1 操作系统与架构确认Codex的安装包对主流系统支持得都比较完整Windows、macOS、Linux都有对应版本。但下载之前先确认你的电脑架构这步做错会导致后面“文件存在但跑不起来”的情况。系统常见架构查看方法Windowsx64 / ARM64设置-系统-关于或命令行输入echo %PROCESSOR_ARCHITECTURE%macOSApple Siliconarm64 / Intelx64左上角苹果图标-关于本机Linuxx64 / arm64终端执行uname -m当前主流电脑绝大多数是x64或Apple Silicon选对应架构的安装包基本没错。如果你的机器是ARM架构的Windows或Linux后面安装时也要找带arm字样的版本。2.2 Node.js版本检测与安装目前版本主要通过npm进行分发所以机器上得有Node.js环境。官方推荐Node.js 18以上我自己建议直接用20或22的LTS版本稳定且兼容性好。可以打开终端执行下面命令看现有版本node -v npm -v如果提示“node不是内部或外部命令”之类的话说明没装或者没加入PATH。装Node.js的方式很多我的建议是到Node.js官网下载LTS安装包一路下一步即可装完重新开一个终端窗口再检测一次。不建议为了贪新追非LTS版本那东西两天一更反而容易给全局工具埋坑。2.3 终端环境与权限准备Windows用户建议用Windows Terminal或者PowerShell别再用老掉牙的cmd很多命令在cmd里显示乱码且编码兼容性差。macOS和Linux用户就用系统自带终端就好。还有一个隐蔽的坑如果你用macOS或者Linux全局安装npm包时大概率会遇到权限问题。常见报错是EACCES意思是当前用户没有权限往全局目录写文件。解决办法是用sudo临时提权或者配置npm的全局路径指向当前用户的目录。后面安装章节会细说这两种方式先记住别上来就硬装。3. 下载安装的三种完整路线选一条照着做3.1 路线一通过npm全局安装推荐给绝大多数人npm全局安装是我最推荐的方式原因很简单一条命令搞定后续升级也方便。打开终端执行npm install -g openai/codex这里有几个细节值得说清楚。-g表示全局安装装完后系统任意目录都能直接调用codex命令openai/codex是官方作用域包名带了openai前缀别装成不带前缀的同名包那个不是官方工具。等命令跑完后执行codex --version如果能输出版本号说明装好了。如果提示codex: command not found多半是npm全局bin目录没有加入系统PATH。可以用下面命令查看npm全局目录npm prefix -g把它输出的路径一般是/usr/local或/opt/homebrew加到PATH里即可。macOS Apple Silicon机器上npm全局目录往往在/opt/homebrew/bin所以如果codex命令找不到优先看看这个路径在不在PATH里。3.2 路线二通过Homebrew安装macOS用户的最优解macOS用户如果装了Homebrew那直接一条命令就行brew install codexHomebrew会把可执行文件放到/opt/homebrew/binApple Silicon或/usr/local/binIntel这两个路径通常已经在PATH里所以不太会遇到找不到命令的问题。它和npm安装的区别主要在更新机制上。npm全局包更新时用npm up -g openai/codex而Homebrew用brew upgrade codex各有各的方便。我个人的习惯是机器上装了Homebrew就用brew没装Homebrew就统一用npm不为了这个专门去装一遍Homebrew。3.3 路线三从官方GitHub仓库下载独立可执行文件这种方式适合不方便用包管理器的环境或者你希望直接拿一个二进制文件到处拷贝的场景。流程分三步打开官方GitHub仓库的Releases页面找到最新发布版本。根据系统选择对应文件。macOS找codex-x86_64-apple-darwin.zip或codex-aarch64-apple-darwin.zipWindows找带pc-windows的文件Linux找带unknown-linux的文件。下载后解压把可执行文件放到一个自己知道的目录比如~/bin或/usr/local/bin然后给全局PATH加上这个目录。举例来说我习惯这么做mkdir -p ~/bin mv codex ~/bin/ chmod x ~/bin/codex export PATH$HOME/bin:$PATH为了让这个PATH设置永久生效还需要把它写进shell配置文件。macOS/Linux常见配置文件是~/.zshrc或~/.bashrc在末尾追加一行export PATH$HOME/bin:$PATH保存后执行source ~/.zshrc或source ~/.bashrc让它生效。3.4 安装完怎么验证最稳妥只输版本号还不够我建议再做一次更完整的验证确认环境依赖都正常codex --version codex --help--version确保包本体能启动--help确保帮助信息和子命令能正常渲染。如果--version正常、--help乱码或者报错多数是终端编码问题Windows下用PowerShell可以临时执行[Console]::OutputEncoding [System.Text.Encoding]::UTF8另外提醒一句装完后如果遇到杀毒软件或系统安全提示拦截先看一眼是不是针对下载的可执行文件因为本地命令行工具的签名机制和常规软件不太一样很多环境首次运行都会触发安全确认。4. 登录与身份认证跑通前的临门一脚4.1 登录前需要准备好什么Codex本体能装好只算第一步真正要用起来必须要身份认证。目前登录方式分两种一种是账号登录适合有账号并且主要用网页版服务的人另一种是API Key登录适合有API访问权限、需要按量计费或者跑批量任务的人。两种方式都需要你有可用的账号和对应的访问凭据这些东西要提前准备好别等到卡住再去找。4.2 用账号方式登录装完后的首次使用直接执行codex login这个命令会尝试打开浏览器跳转到账号授权页面。浏览器如果正常打开页面上会出现一段授权码将它复制后粘贴回终端确认授权。如果浏览器没自动打开终端里会显示一个授权链接和备用码手动复制链接到浏览器访问也可以。登录成功后本地会保存一份凭据下次使用就不需要重复登录了。这里有一个容易卡住的点终端提示“等待设备激活”或者“请在浏览器中打开…”很多人以为卡死了。其实这是设备授权流程的正常表现只要没报错耐心等浏览器打开并完成认证就好。授权完成后终端会自动跳回正常可用状态。4.3 用API Key方式登录如果你习惯用API Key方式同样简单codex login --api-key回车后会让你粘贴API Key粘贴后按回车确认。需要注意API Key粘贴后终端不会显示字符回显这是正常设计不是键盘坏了。还有一类常见做法是直接把API Key写进环境变量很多CI/CD和批量脚本场景都这么干。设置方式export OPENAI_API_KEY你的API KeyLinux/macOS可以写进~/.zshrc或~/.bashrcWindows可以在系统环境变量里新建OPENAI_API_KEY。当环境变量和配置文件取值同时存在时环境变量的优先级通常会更高这算是个隐藏规则遇到“我明明改了配置却不生效”的问题时可以优先排查环境变量。4.4 登录验证阶段最常见的坑我整理了几个容易踩雷的点按出现频率排序现象原因解决方式登录后启动还是提示未认证授权流程没走完就关了终端重新执行codex login走完整流程API Key粘贴后立刻提示无效Key复制多了空格或因过期失效重新生成Key并确认无多余字符浏览器打开但页面白屏本地服务和授权页之间握手失败关掉代理插件或更换默认浏览器再试多账号切换后状态不对本地凭据缓存的是旧账号查看登录状态命令或删除旧凭据重新登录关于多账号Codex会有查看当前登录状态的命令忘记的话执行codex login --status这类查询命令看看情况。如果确实要换账号先退出再重新登录别直接覆盖。5. config.toml配置详解让它更懂你的工作习惯5.1 配置文件在哪、怎么创建登录成功之后我建议立刻去改一下配置文件。这个文件的主要作用是定义模型选择、执行权限、工作目录等行为偏好相当于给Codex定制一套“工作守则”。配置文件默认放在用户主目录下的.codex目录里最典型路径是~/.codex/config.toml。第一次安装后这个目录可能还不存在需要手动创建mkdir -p ~/.codex touch ~/.codex/config.toml5.2 常用的配置项与含义配置文件的核心语法是TOML格式键值对分组结构比较简单。一般会从几个维度去配置。第一个是默认模型。不同模型在处理复杂任务时的能力和成本差异很大如果想让Codex默认使用某个指定模型可以在配置文件开头写上model gpt-5-codex第二个是执行权限。Codex最让人不放心的地方就是它会执行命令。默认情况下它会在执行敏感操作前征求同意你可以通过配置调整这个策略。比如我习惯把它设置成“允许写文件但执行高风险命令需要确认”[approval_policy] mode workspace_write这里的模式还可以按需调整成更严格或更宽松的模式。严格模式适合生产环境、重要项目每次动作都确认宽松模式适合自己私下研究、写脚本效率高但风险自担。新手我建议从严格模式开始跑熟了再放宽。第三个是作用域和工作目录。你可以配置它默认只能在某个项目目录内操作避免它跨目录读文件。示例[project] default_dir /path/to/my/project第四个是MCP服务配置。MCP可以理解成给AI扩展外部工具能力的协议比如让它能调浏览器、查文档、访问特定API。如果你有现成的MCP服务地址可以写进配置文件里官方文档对这块有详细字段说明这边不多赘述。5.3 配置修改后如何确认生效改完配置文件后重启Codex会话才会加载新配置。有些小伙伴改完没重启然后发现配置“没变”其实只是没有重新读取。启动后可以查看当前生效的配置项确认配置有没有加载成功codex exec --config或者直接执行codex exec 列出当前项目结构这种带实际动作的命令观察它是否按你的配置权限来执行。另外需要提醒的是配置文件里不要写明文API Key不要提交到git仓库也不要在截图里发出去。凭据放环境变量或专门的安全存储里配置文件只放行为和偏好相关的内容。6. 第一次实战从空目录到跑通一个任务6.1 准备一个干净的练习目录正式使用前建议先造一个临时项目目录来练手不要一上来就在真实生产仓库里跑。我习惯这样做mkdir -p ~/codex-demo cd ~/codex-demo在这个空目录里启动Codex它就能完全专注在当前项目不会误读其他文件。6.2 交互式会话跑一遍完整流程在当前目录里直接执行codex启动后你会进入一个对话界面类似于聊天窗口但基于终端。这时我一般会提一个带明确验收标准的需求比如“在这个目录里创建一个Python脚本名字叫rename_files.py功能是把当前目录下所有.jpg后缀文件按photo_001.jpg这种顺序重命名重命名之前先打印每个文件的旧名字和新名字。”提完之后Codex会开始分析目录、写文件、执行命令。它可能会要求运行权限审查命令后选择允许。整个过程你会看到它一会儿读文件一会儿写代码一会儿执行终端命令就像有个同事坐在旁边干活。跑完之后检查一下目录里生成的文件内容。这一步别省AI写的代码一定要人审重点看命名逻辑、边界情况、是否有意外覆盖文件的隐患。6.3 用非交互模式执行一次性任务除了进入交互会话Codex还支持直接传一条命令执行适合放到脚本里或快速跑单任务。语法如下codex exec 列出当前目录下所有文件并按文件大小排序非交互模式执行时它会把结果直接输出到终端后退出不会进入对话循环。这个模式在处理批量任务时非常好用我一般把它用在处理日志、整理报表、批量生成测试数据这些场景。个人建议是第一次跑任务一定要盯着看了解它的行为模式后再放手。等摸清它的脾气再让它独立处理小改动也不迟。7. 高频问题自救手册遇到报错先看这里7.1 安装阶段的报错npm安装时提示EACCES权限不足这个太常见了。要么临时用sudo提权要么给npm配当前用户的全局目录。我建议优先改全局目录毕竟长期用sudo毕竟风险大执行mkdir -p ~/.npm-global npm config set prefix ~/.npm-global再把全局bin目录加入PATH写入shell配置文件后重新加载。以后npm全局装的工具都进这个目录不会再和系统目录抢权限。Windows下npm安装后提示执行策略禁止脚本PowerShell默认执行策略会拦截一些脚本报错中带着Set-ExecutionPolicy字样时可以这样修复Set-ExecutionPolicy RemoteSigned -Scope CurrentUser设置之后再执行codex --version验证。macOS提示“无法打开因为无法验证开发者”独立可执行文件第一次运行时偶尔会触发系统安全拦截。两个思路一是右键文件选“打开”并确认系统会放行这次二是用xattr -dr com.apple.quarantine ~/bin/codex清除隔离属性。第二种操作有安全风险只建议在完全信任来源时使用。7.2 会话阶段的报错启动后卡在“connecting”类似的状态一般是网络到服务端的握手出了问题排查顺序建议是先用codex login --status确认登录状态再检查本地安全软件、系统代理和网络出口是否正常。很多代理类工具会改全局网络设置导致连接不稳定可以试试临时关闭再启动会话。提示“model not found”或“model不存在”这种情况通常是你指定了一个较旧、已下线或不存在的模型名。先检查配置文件里的model字段是包正确再查看当前可用模型列表换一个可用模型再试。执行任务时被频繁打断原因是权限确认策略比较严格。如果是自己的练习项目可以把approval_policy调成宽松模式如果是生产项目还是保持严格确认模式吧频繁打断总比误删文件强。7.3 关于账号配额与模型选择的建议账号的用量和频率限制是现实中很多人卡住的点。具体配额因账号类型和当前服务政策而异遇到“额度已用尽”这类提示时处理办法要么等额度刷新要么换成更轻量的模型要么检查账号的额度上限。建议在启动任务之前查一下当前账号可用额度和模型支持情况别等任务跑一半才发现额度不够。8. 最后聊几句实在的使用心得这套流程前前后后我跑了好几遍印象最深的一点是真正让Codex发挥价值的不是“它能写多少代码”而是“你敢不敢放手让它读代码、执行命令”。一开始我老是把它限制得死死的每个操作都要手动确认结果效率没比手动写快多少。后来在测试项目里逐步放开权限才体会到那种“你描述需求、它干活、你做代码评审”的顺畅感。如果你也是刚开始接触这个工具我建议按这三步走先用严格权限模式在临时目录里跑通全流程然后慢慢找到一个让你放心的授权边界最后再把它接入实际项目。所有自动工具的第一原则都是一样的——它干活你把关。希望这份教程能帮你少踩几个坑。
近两年来“AI写代码”已经从概念变成了很多开发者的日常工作流而Codex就是这波变化里关注度极高的一款终端工具。它由OpenAI团队维护提供了一个本地命令行环境让AI可以直接读取项目文件、运行命令、修改代码而不是像网页聊天那样只给一段代码建议、再让人手动去粘贴。对于平时习惯用VS Code、终端或者SSH远程开发的人Codex更像一个住进终端里的编程搭档。这篇文章我会按当前最新版本环境从下载、安装、登录、配置到跑通第一个任务整理出一份能跟着一步步操作的手把手流程哪怕你之前只会在浏览器里用AI看完之后也能把本地版Codex支棱起来。1. Codex是什么下载前先搞清楚的事1.1 从“代码补全”到“终端里的开发搭档”很多朋友第一次听到Codex会以为它是某个老模型的名字这个理解不算错但也不完整。早几年确实有过一个叫Codex的模型擅长把自然语言转成代码片段而现在的Codex是一个完全不同的东西——它是官方发布的终端工具底层接入了新一代大模型同时把文件读取、命令行执行、代码修改这些能力都打通了。你可以把它理解成“一个住在终端里的AI开发助理”。它和网页版聊天工具的核心区别在于上下文和权限。网页版对话里AI只能看到你手动复制进去的代码片段而Codex在你本地的项目目录里启动后能直接扫描目录结构、读取文件内容、建立索引然后基于项目真实状态去改代码、执行测试、运行脚本。你不再需要反复复制粘贴上下文只要把任务描述清楚它就自己去看代码仓库里的情况。1.2 它具体能帮你做什么我实际用下来Codex最顺手的几个场景是新项目起步在空目录里让它生成一个完整的脚手架比如“用Python写一个带命令行参数的批量文件重命名工具”它会直接创建文件、装依赖、给出运行说明。修bug把当前报错贴给它它能顺着调用链找到可疑代码改完还能跑一遍测试确认。批量重构比如把项目里所有旧的日志写法替换成统一的日志组件这种重复但有风险的活交给它做比手工改安全得多。写一次性脚本临时处理Excel表格、批量压图片、拉取某个接口数据并整理成JSON这类脚本我不想留着直接让它生成并执行完事就删。它就像一个对代码库“有记忆”的助手前提是你给了它正确的任务边界和执行权限。1.3 别把Codex当“魔法棒”当然它也有不合适的地方。如果你希望它一次就生成一个几千行、零缺陷的商业系统那大概率会失望如果项目里有大量历史遗留的复杂业务逻辑、极难搜索的隐性规则它也可能给出表面合理但实际有问题的方案。更要紧的是它会执行终端命令所以遇到它主动提“要不要删文件”“要不要执行某个命令”的时候务必看清楚再确认。我的原则是它负责“写”和“改”我负责“审”和“放行”。2. 安装前的环境自查三件事最容易翻车2.1 操作系统与架构确认Codex的安装包对主流系统支持得都比较完整Windows、macOS、Linux都有对应版本。但下载之前先确认你的电脑架构这步做错会导致后面“文件存在但跑不起来”的情况。系统常见架构查看方法Windowsx64 / ARM64设置-系统-关于或命令行输入echo %PROCESSOR_ARCHITECTURE%macOSApple Siliconarm64 / Intelx64左上角苹果图标-关于本机Linuxx64 / arm64终端执行uname -m当前主流电脑绝大多数是x64或Apple Silicon选对应架构的安装包基本没错。如果你的机器是ARM架构的Windows或Linux后面安装时也要找带arm字样的版本。2.2 Node.js版本检测与安装目前版本主要通过npm进行分发所以机器上得有Node.js环境。官方推荐Node.js 18以上我自己建议直接用20或22的LTS版本稳定且兼容性好。可以打开终端执行下面命令看现有版本node -v npm -v如果提示“node不是内部或外部命令”之类的话说明没装或者没加入PATH。装Node.js的方式很多我的建议是到Node.js官网下载LTS安装包一路下一步即可装完重新开一个终端窗口再检测一次。不建议为了贪新追非LTS版本那东西两天一更反而容易给全局工具埋坑。2.3 终端环境与权限准备Windows用户建议用Windows Terminal或者PowerShell别再用老掉牙的cmd很多命令在cmd里显示乱码且编码兼容性差。macOS和Linux用户就用系统自带终端就好。还有一个隐蔽的坑如果你用macOS或者Linux全局安装npm包时大概率会遇到权限问题。常见报错是EACCES意思是当前用户没有权限往全局目录写文件。解决办法是用sudo临时提权或者配置npm的全局路径指向当前用户的目录。后面安装章节会细说这两种方式先记住别上来就硬装。3. 下载安装的三种完整路线选一条照着做3.1 路线一通过npm全局安装推荐给绝大多数人npm全局安装是我最推荐的方式原因很简单一条命令搞定后续升级也方便。打开终端执行npm install -g openai/codex这里有几个细节值得说清楚。-g表示全局安装装完后系统任意目录都能直接调用codex命令openai/codex是官方作用域包名带了openai前缀别装成不带前缀的同名包那个不是官方工具。等命令跑完后执行codex --version如果能输出版本号说明装好了。如果提示codex: command not found多半是npm全局bin目录没有加入系统PATH。可以用下面命令查看npm全局目录npm prefix -g把它输出的路径一般是/usr/local或/opt/homebrew加到PATH里即可。macOS Apple Silicon机器上npm全局目录往往在/opt/homebrew/bin所以如果codex命令找不到优先看看这个路径在不在PATH里。3.2 路线二通过Homebrew安装macOS用户的最优解macOS用户如果装了Homebrew那直接一条命令就行brew install codexHomebrew会把可执行文件放到/opt/homebrew/binApple Silicon或/usr/local/binIntel这两个路径通常已经在PATH里所以不太会遇到找不到命令的问题。它和npm安装的区别主要在更新机制上。npm全局包更新时用npm up -g openai/codex而Homebrew用brew upgrade codex各有各的方便。我个人的习惯是机器上装了Homebrew就用brew没装Homebrew就统一用npm不为了这个专门去装一遍Homebrew。3.3 路线三从官方GitHub仓库下载独立可执行文件这种方式适合不方便用包管理器的环境或者你希望直接拿一个二进制文件到处拷贝的场景。流程分三步打开官方GitHub仓库的Releases页面找到最新发布版本。根据系统选择对应文件。macOS找codex-x86_64-apple-darwin.zip或codex-aarch64-apple-darwin.zipWindows找带pc-windows的文件Linux找带unknown-linux的文件。下载后解压把可执行文件放到一个自己知道的目录比如~/bin或/usr/local/bin然后给全局PATH加上这个目录。举例来说我习惯这么做mkdir -p ~/bin mv codex ~/bin/ chmod x ~/bin/codex export PATH$HOME/bin:$PATH为了让这个PATH设置永久生效还需要把它写进shell配置文件。macOS/Linux常见配置文件是~/.zshrc或~/.bashrc在末尾追加一行export PATH$HOME/bin:$PATH保存后执行source ~/.zshrc或source ~/.bashrc让它生效。3.4 安装完怎么验证最稳妥只输版本号还不够我建议再做一次更完整的验证确认环境依赖都正常codex --version codex --help--version确保包本体能启动--help确保帮助信息和子命令能正常渲染。如果--version正常、--help乱码或者报错多数是终端编码问题Windows下用PowerShell可以临时执行[Console]::OutputEncoding [System.Text.Encoding]::UTF8另外提醒一句装完后如果遇到杀毒软件或系统安全提示拦截先看一眼是不是针对下载的可执行文件因为本地命令行工具的签名机制和常规软件不太一样很多环境首次运行都会触发安全确认。4. 登录与身份认证跑通前的临门一脚4.1 登录前需要准备好什么Codex本体能装好只算第一步真正要用起来必须要身份认证。目前登录方式分两种一种是账号登录适合有账号并且主要用网页版服务的人另一种是API Key登录适合有API访问权限、需要按量计费或者跑批量任务的人。两种方式都需要你有可用的账号和对应的访问凭据这些东西要提前准备好别等到卡住再去找。4.2 用账号方式登录装完后的首次使用直接执行codex login这个命令会尝试打开浏览器跳转到账号授权页面。浏览器如果正常打开页面上会出现一段授权码将它复制后粘贴回终端确认授权。如果浏览器没自动打开终端里会显示一个授权链接和备用码手动复制链接到浏览器访问也可以。登录成功后本地会保存一份凭据下次使用就不需要重复登录了。这里有一个容易卡住的点终端提示“等待设备激活”或者“请在浏览器中打开…”很多人以为卡死了。其实这是设备授权流程的正常表现只要没报错耐心等浏览器打开并完成认证就好。授权完成后终端会自动跳回正常可用状态。4.3 用API Key方式登录如果你习惯用API Key方式同样简单codex login --api-key回车后会让你粘贴API Key粘贴后按回车确认。需要注意API Key粘贴后终端不会显示字符回显这是正常设计不是键盘坏了。还有一类常见做法是直接把API Key写进环境变量很多CI/CD和批量脚本场景都这么干。设置方式export OPENAI_API_KEY你的API KeyLinux/macOS可以写进~/.zshrc或~/.bashrcWindows可以在系统环境变量里新建OPENAI_API_KEY。当环境变量和配置文件取值同时存在时环境变量的优先级通常会更高这算是个隐藏规则遇到“我明明改了配置却不生效”的问题时可以优先排查环境变量。4.4 登录验证阶段最常见的坑我整理了几个容易踩雷的点按出现频率排序现象原因解决方式登录后启动还是提示未认证授权流程没走完就关了终端重新执行codex login走完整流程API Key粘贴后立刻提示无效Key复制多了空格或因过期失效重新生成Key并确认无多余字符浏览器打开但页面白屏本地服务和授权页之间握手失败关掉代理插件或更换默认浏览器再试多账号切换后状态不对本地凭据缓存的是旧账号查看登录状态命令或删除旧凭据重新登录关于多账号Codex会有查看当前登录状态的命令忘记的话执行codex login --status这类查询命令看看情况。如果确实要换账号先退出再重新登录别直接覆盖。5. config.toml配置详解让它更懂你的工作习惯5.1 配置文件在哪、怎么创建登录成功之后我建议立刻去改一下配置文件。这个文件的主要作用是定义模型选择、执行权限、工作目录等行为偏好相当于给Codex定制一套“工作守则”。配置文件默认放在用户主目录下的.codex目录里最典型路径是~/.codex/config.toml。第一次安装后这个目录可能还不存在需要手动创建mkdir -p ~/.codex touch ~/.codex/config.toml5.2 常用的配置项与含义配置文件的核心语法是TOML格式键值对分组结构比较简单。一般会从几个维度去配置。第一个是默认模型。不同模型在处理复杂任务时的能力和成本差异很大如果想让Codex默认使用某个指定模型可以在配置文件开头写上model gpt-5-codex第二个是执行权限。Codex最让人不放心的地方就是它会执行命令。默认情况下它会在执行敏感操作前征求同意你可以通过配置调整这个策略。比如我习惯把它设置成“允许写文件但执行高风险命令需要确认”[approval_policy] mode workspace_write这里的模式还可以按需调整成更严格或更宽松的模式。严格模式适合生产环境、重要项目每次动作都确认宽松模式适合自己私下研究、写脚本效率高但风险自担。新手我建议从严格模式开始跑熟了再放宽。第三个是作用域和工作目录。你可以配置它默认只能在某个项目目录内操作避免它跨目录读文件。示例[project] default_dir /path/to/my/project第四个是MCP服务配置。MCP可以理解成给AI扩展外部工具能力的协议比如让它能调浏览器、查文档、访问特定API。如果你有现成的MCP服务地址可以写进配置文件里官方文档对这块有详细字段说明这边不多赘述。5.3 配置修改后如何确认生效改完配置文件后重启Codex会话才会加载新配置。有些小伙伴改完没重启然后发现配置“没变”其实只是没有重新读取。启动后可以查看当前生效的配置项确认配置有没有加载成功codex exec --config或者直接执行codex exec 列出当前项目结构这种带实际动作的命令观察它是否按你的配置权限来执行。另外需要提醒的是配置文件里不要写明文API Key不要提交到git仓库也不要在截图里发出去。凭据放环境变量或专门的安全存储里配置文件只放行为和偏好相关的内容。6. 第一次实战从空目录到跑通一个任务6.1 准备一个干净的练习目录正式使用前建议先造一个临时项目目录来练手不要一上来就在真实生产仓库里跑。我习惯这样做mkdir -p ~/codex-demo cd ~/codex-demo在这个空目录里启动Codex它就能完全专注在当前项目不会误读其他文件。6.2 交互式会话跑一遍完整流程在当前目录里直接执行codex启动后你会进入一个对话界面类似于聊天窗口但基于终端。这时我一般会提一个带明确验收标准的需求比如“在这个目录里创建一个Python脚本名字叫rename_files.py功能是把当前目录下所有.jpg后缀文件按photo_001.jpg这种顺序重命名重命名之前先打印每个文件的旧名字和新名字。”提完之后Codex会开始分析目录、写文件、执行命令。它可能会要求运行权限审查命令后选择允许。整个过程你会看到它一会儿读文件一会儿写代码一会儿执行终端命令就像有个同事坐在旁边干活。跑完之后检查一下目录里生成的文件内容。这一步别省AI写的代码一定要人审重点看命名逻辑、边界情况、是否有意外覆盖文件的隐患。6.3 用非交互模式执行一次性任务除了进入交互会话Codex还支持直接传一条命令执行适合放到脚本里或快速跑单任务。语法如下codex exec 列出当前目录下所有文件并按文件大小排序非交互模式执行时它会把结果直接输出到终端后退出不会进入对话循环。这个模式在处理批量任务时非常好用我一般把它用在处理日志、整理报表、批量生成测试数据这些场景。个人建议是第一次跑任务一定要盯着看了解它的行为模式后再放手。等摸清它的脾气再让它独立处理小改动也不迟。7. 高频问题自救手册遇到报错先看这里7.1 安装阶段的报错npm安装时提示EACCES权限不足这个太常见了。要么临时用sudo提权要么给npm配当前用户的全局目录。我建议优先改全局目录毕竟长期用sudo毕竟风险大执行mkdir -p ~/.npm-global npm config set prefix ~/.npm-global再把全局bin目录加入PATH写入shell配置文件后重新加载。以后npm全局装的工具都进这个目录不会再和系统目录抢权限。Windows下npm安装后提示执行策略禁止脚本PowerShell默认执行策略会拦截一些脚本报错中带着Set-ExecutionPolicy字样时可以这样修复Set-ExecutionPolicy RemoteSigned -Scope CurrentUser设置之后再执行codex --version验证。macOS提示“无法打开因为无法验证开发者”独立可执行文件第一次运行时偶尔会触发系统安全拦截。两个思路一是右键文件选“打开”并确认系统会放行这次二是用xattr -dr com.apple.quarantine ~/bin/codex清除隔离属性。第二种操作有安全风险只建议在完全信任来源时使用。7.2 会话阶段的报错启动后卡在“connecting”类似的状态一般是网络到服务端的握手出了问题排查顺序建议是先用codex login --status确认登录状态再检查本地安全软件、系统代理和网络出口是否正常。很多代理类工具会改全局网络设置导致连接不稳定可以试试临时关闭再启动会话。提示“model not found”或“model不存在”这种情况通常是你指定了一个较旧、已下线或不存在的模型名。先检查配置文件里的model字段是包正确再查看当前可用模型列表换一个可用模型再试。执行任务时被频繁打断原因是权限确认策略比较严格。如果是自己的练习项目可以把approval_policy调成宽松模式如果是生产项目还是保持严格确认模式吧频繁打断总比误删文件强。7.3 关于账号配额与模型选择的建议账号的用量和频率限制是现实中很多人卡住的点。具体配额因账号类型和当前服务政策而异遇到“额度已用尽”这类提示时处理办法要么等额度刷新要么换成更轻量的模型要么检查账号的额度上限。建议在启动任务之前查一下当前账号可用额度和模型支持情况别等任务跑一半才发现额度不够。8. 最后聊几句实在的使用心得这套流程前前后后我跑了好几遍印象最深的一点是真正让Codex发挥价值的不是“它能写多少代码”而是“你敢不敢放手让它读代码、执行命令”。一开始我老是把它限制得死死的每个操作都要手动确认结果效率没比手动写快多少。后来在测试项目里逐步放开权限才体会到那种“你描述需求、它干活、你做代码评审”的顺畅感。如果你也是刚开始接触这个工具我建议按这三步走先用严格权限模式在临时目录里跑通全流程然后慢慢找到一个让你放心的授权边界最后再把它接入实际项目。所有自动工具的第一原则都是一样的——它干活你把关。希望这份教程能帮你少踩几个坑。
