Codex CLI零基础教程:从安装配置到接入DeepSeek全攻略
最近后台收到一大堆关于Codex的私信怎么安装、怎么登录、为什么一直报错、能不能接DeepSeek、Windows是不是装不上……能看出来很多人是真的想学但卡在了第一步。我自己从Codex还在alpha阶段就开始折腾一路踩坑踩到怀疑人生现在基本每天都会在终端里用它处理开发任务。这篇教程我干脆按零基础的路径来写先讲清楚Codex是什么、能干什么再一步步把环境装好、登录好、配置好接着跑通一个真实任务最后把接入DeepSeek的方法和高频报错的排查方案完整给出来。没基础也完全能跟上全程不用理解太深的理论照着复制命令就行。1. 认识Codex它到底能帮你干什么1.1 从一个例子看Codex的工作方式先说明白Codex不是一个聊天网站也不是一个非要装在编辑器里的插件虽然它确实有配套插件。它是OpenAI开源的一个终端命令行编程助手官方叫Codex CLI底层调用GPT系列模型靠自然语言指令驱动它干活。举个最直观的例子。你在项目目录下输入这么一句codex exec 统计一下这个项目里所有Python文件总共有多少行Codex会先拆解需求然后自己去找文件、执行shell命令、统计结果、整理输出。它不是“你问一句它答一句”而是真的会动手读文件、改代码、跑命令、看报错再决定下一步干什么。这种感觉更像带了一个实习生你交代任务它执行再把结果反馈给你哪里有问题还会尝试自己修。1.2 Codex能干的四类典型任务用了一段时间之后我把Codex的实用场景归纳成四类新手先把这几类搞清楚后面就不迷茫。代码库问答让Codex读整个项目回答“这个模块是干嘛的”“登录逻辑在哪里”“为什么这里报空指针”这类问题。它像个24小时在线的代码陪读比你自己翻文件快得多。自动改代码直接下修改指令比如“把支付接口的超时时间从30秒改成60秒并补上对应的单元测试”。它会自己定位相关文件、改动代码、跑测试确认结果。这类活占我日常使用的一半以上。执行终端命令批量重命名文件、查日志、跑脚本、统计数据只要是终端里能做的操作都能丢给它。尤其适合那些你懒得手敲的长命令。写文档和整理杂活生成README、整理变更记录、把一段报错翻译成人话、把聊天记录提炼成会议纪要这些琐事它处理得很稳。1.3 它和Cursor、Copilot这类工具的区别很多朋友问我都在用Cursor了为什么还要学Codex我的看法是它们不是替代关系。Cursor和Copilot的核心体验是在编辑器里补全代码、对话修改而Codex的主场是终端和命令行强调的是“Agent式自主执行”。Codex有三个其他工具不好替代的优势一是轻一个CLI工具SSH到服务器上也能用不用开图形界面二是透明每一步做了什么都在终端里实时显示你可以随时叫停三是可配置模型来源官方通过model_provider机制支持接入不同的兼容服务这就引出了后面要讲的DeepSeek玩法。如果你是命令行重度用户或者经常需要远程操作服务器Codex会顺手得多如果你只想要IDE里的代码提示继续用Cursor和Copilot完全没问题。2. 零基础安装全流程从Node.js到Codex2.1 先说系统环境安装之前先确认你用的是哪套系统。Codex官方对macOS和Linux的支持最顺滑Windows用户我不建议直接在PowerShell里硬装——虽然新版已经能跑但依赖环境很容易缺这缺那后面会专门说Windows怎么处理。建议的路线是这样macOS直接用自带终端Linux服务器或桌面直接用终端Windows装一个WSL 2再装Ubuntu在Ubuntu环境里操作体验和Linux完全一致。先跑两个命令确认基础情况uname -a node -v如果node命令报不存在看下面的安装步骤。2.2 安装Node.js与npmCodex是用npm分发的全局工具所以Node.js和npm是前置条件。版本上建议Node.js 18以上我目前用的是20的LTS版本用起来一直很省心。macOS用户装了Homebrew的话一行搞定brew install nodeLinux用户按系统来。Ubuntu/Debian可以用apt安装但系统源里的Node版本经常偏老我更推荐用nvm来装版本随时能切curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 20 nvm use 20装完验证一下node -v npm -v能打印出版本号这一步就算过了。2.3 安装Codex本体环境就绪后安装Codex就是一条命令的事npm install -g openai/codex如果npm拉包很慢可以把registry临时切到国内的npmmirror镜像源装完再切回来。这不是什么特殊操作就是普通的npm镜像配置npm config set registry https://registry.npmmirror.com npm install -g openai/codex除了npm安装官方在GitHub Releases页面也提供预编译的安装包下载对应系统的压缩包解压后把codex二进制放到PATH路径里就行。日常建议用npm方式升级方便如果你的网络环境不适合走npm再考虑下载安装包。以后升级只需要npm update -g openai/codex2.4 验证安装是否成功装完第一步先看版本号codex --version能看到版本号就说明装上了。接着建议跑一下codex --help这里会列出所有子命令和参数不用全看懂先有个印象后面讲到哪个就回来看哪个。这里有一个新手最容易踩的坑终端提示command not found。原因通常是npm的全局bin目录不在PATH里。用npm prefix -g查看目录位置把这个目录加到~/.zshrc或~/.bashrc的PATH里重新打开终端就好了。2.5 Windows用户的“设置未完成”问题现在专门说Windows。很多人搜到“codex windows设置未完成”这个报错多半是在Windows原生环境里安装时Codex依赖的一些Unix工具和权限环境没有就绪。我的建议很直接别在原生Windows里较劲直接上WSL 2。步骤不复杂。先以管理员身份打开PowerShell执行wsl --install重启后安装Ubuntu发行版打开Ubuntu终端然后在里面按2.2和2.3的步骤装Node.js和Codex。之后把Windows Terminal切换到WSL会话就能像在Linux里一样使用Codex了。如果你平时用VS Code再装一个Remote - WSL插件直接打开WSL里的项目文件夹终端自动就是WSL环境体验很顺。这个过程中唯一要留意的是WSL里执行codex login时浏览器授权会用到本地回调端口如果杀毒软件拦截了要放行。3. 登录与配置让Codex认识你的账号3.1 用ChatGPT账号登录安装只是第一步登录才是真正能用的开始。如果你用ChatGPT账号授权运行codex login它会尝试拉起浏览器进入授权页面同意之后凭证会自动写到~/.codex/auth.json。这个过程完成后Codex就拥有你账号对应的模型调用权限了。这里有个关键前提Codex所在的环境必须能正常访问OpenAI的服务页面。如果你当前网络访问不了登录这关就会卡住。遇到这种情况先把网络连通性问题处理掉再继续注意不要去手动改auth.json那个文件有格式校验改坏了反而更难排查。登录成功的判断标准很直接随便让Codex说句话codex exec 用一句话介绍你自己它能正常回复就说明登录和接口调用全部通了。3.2 用API Key登录如果你不想绑定ChatGPT账号或者想走独立计费的API方式可以用API Key登录codex login --api-key按提示粘贴你的key就行。也可以用环境变量的方式在shell配置里加一行export OPENAI_API_KEYsk-你的key两种方式等价看个人习惯。我推荐环境变量方式因为key不落在Codex自己的凭证文件里服务器部署时更灵活多项目切换不至于互相污染。3.3 看懂config.tomlCodex的“大脑配置”Codex的配置文件在~/.codex/config.toml这是Codex的“大脑配置”。零基础朋友第一次打开它可能会懵但核心键没几个我贴一个带注释的常用骨架model gpt-5 model_provider openai [model_providers.openai] name OpenAI base_url https://api.openai.com/v1 env_key OPENAI_API_KEY wire_api responses这个文件里model决定用哪个模型model_provider决定路由到哪个服务方。下面的[model_providers.xxx]区域就是在自定义服务方后面接DeepSeek就是在这个地方动手。除了这两个核心键还有organization_id用来指定组织sandbox_mode设置默认沙箱级别approval_policy控制审批策略。新手先保持最小可用别一股脑堆配置改错了后面会讲怎么排查。3.4 登录不上与“无法加载组织设置”怎么排查登录环节的问题集中在两类。第一类是登录不上浏览器打不开或者授权完没反应。最常见的原因有三个浏览器没被正确唤起、授权页网络不通、本机时间不同步导致OAuth校验失败。排查建议先检查系统时间是否准确再用浏览器手工打开授权地址试试最后看命令行输出的错误码去官方仓库或社区搜索。第二类是登录完成了但使用时报“无法加载组织设置”或类似提示。这种一般是获取组织信息的接口调用失败原因要么是凭证过期要么是网络请求没发出去要么是环境变量里配了一个不存在的组织ID。处理顺序建议先重新登录一次刷新凭证再检查有没有设置OPENAI_ORGANIZATION临时清掉最后确认网络能正常访问服务。如果还是不行在配置里显式指定organization_id再试。4. 核心操作exec、chat与沙箱机制4.1 codex exec一次性任务就靠它Codex最常用的子命令是exec含义是“执行”。用法就是一句话加一个任务描述codex exec 找出当前目录下最大的三个文件并打印它们的路径和大小Codex收到任务后会先规划然后一步步读取目录、执行命令、收集结果。这个过程中你可以清楚看到它准备跑什么命令默认情况下敏感操作会等你确认。如果你确定任务安全想让它一口气干完加一个参数codex exec --full-auto 把src目录里所有console.log都删除full-auto的意思是自动批准它发起的操作不用每次点确认。但要提醒一句full-auto不等于无限制它仍然受沙箱约束默认只能改当前工作区内的内容读不了你系统里的其他隐私文件。有人问有没有汉化版其实CLI界面就是英文的但命令和选项就那么几十个照着教程用几次就熟了真不需要汉化。4.2 codex chat交互式连续对话难度更高一点的任务推荐用chat模式。运行codex chat你会进入一个交互式对话界面可以连续追问。比如先让它解释一段代码再接着让它“帮我把这个函数拆成两个”它会在同一个上下文里回你并且展示每次操作的状态。这种模式很适合“先探索后修改”的工作流我调试复杂问题基本都用chat。如果你只是想快速验证一个问题直接输入codex回车也能进入类似的交互界面效果差不多看个人习惯。4.3 沙箱机制Codex的安全护栏沙箱是Codex安全设计的核心零基础阶段必须搞懂。它的本质是给Codex“能干什么”划边界默认有三种级别read-only只能读文件不能写任何文件也不能执行可能产生副作用的命令。适合让Codex解释代码、分析项目。workspace-write可以读写当前工作区内的文件但触及工作区之外的目录会被拦住。这是默认级别日常开发最常用。dangerous不受限制可以读写任意路径、执行任意命令。这是最后一个选项真要用就自己承担后果。跑任务时用--sandbox指定级别codex exec --sandbox read-only 分析一下这个项目的模块结构我见过不少新手一上来就开dangerous然后Codex稀里糊涂删了一堆文件心态直接崩溃。原则很简单默认用workspace-write只有你自己完全清楚风险时才用dangerous。4.4 常用参数速查表我把日常最常用的参数整理成一张表新手存下来对照着用就行。参数作用示例--full-auto自动批准操作不用逐个确认codex exec --full-auto 修复构建错误--sandbox指定沙箱级别codex exec --sandbox read-only 读一下README--model指定模型名codex exec --model deepseek-chat 写一个脚本--model-provider指定模型服务方codex exec --model-provider deepseek ...-C切换到指定目录执行codex exec -C /path/to/project ...--json以JSON格式输出结果codex exec --json ...--continue延续之前会话的上下文codex exec --continue 继续刚才的任务用熟了会发现多数时候只需要记住exec、--full-auto和--sandbox这三个其他用到再查就行。5. 进阶玩法把Codex接入DeepSeek5.1 为什么要接第三方模型OpenAI账号和API Key不是每个人都有也不是谁都方便开通支付。这时候“给Codex换一个模型来源”就成了刚需。Codex本身支持多模型服务商只要服务商提供OpenAI兼容接口就能接进来。DeepSeek是目前社区里最热的选择它提供兼容OpenAI格式的API模型调用费用低中文环境下生成代码的口碑很好。所以“Codex接入DeepSeek”这个玩法本质就是给Codex换了一个更便宜、更方便的“大脑”。5.2 先理解model_provider与wire_api接之前要理解两个概念。model_provider是Codex里对“模型服务方”的抽象一个provider由几个字段描述name是显示名base_url是接口地址env_key指定从哪个环境变量读API Keywire_api是接口协议类型。第二个概念wire_api它有两个值responses和chat。OpenAI自己最新的接口走responses协议而绝大多数兼容服务包括DeepSeek走的是chat/completions协议。接DeepSeek时wire_api一定要设成chat这是最容易翻车的地方。5.3 一份可以直接抄的DeepSeek配置先在DeepSeek开放平台注册并创建一个API Key记下那串sk开头的key。然后打开~/.codex/config.toml在文件里加一个provider同时把默认模型指向它model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat然后在shell配置里导出DeepSeek Keyexport DEEPSEEK_API_KEYsk-你的DeepSeek密钥保存配置后验证一下codex exec --model-provider deepseek --model deepseek-chat 写一个Python函数计算斐波那契数列能正常输出代码就说明接入成功了。之后默认配置里model已经是deepseek-chat如果不指定providerCodex就会优先用DeepSeek干活。OpenAI的provider还在配置里保留着想切回去就改model_provider或者用命令行参数临时覆盖。5.4 模型选择、费用对比与实操建议DeepSeek主要提供两个模型deepseek-chat适合日常对话和写代码速度快、成本低deepseek-reasoner带深度推理适合难题拆解、算法设计速度慢一点价格也更高。我的日常习惯是默认用deepseek-chat遇到复杂逻辑才临时换reasoner。费用方面最直观Codex默认用官网模型是按账号或API独立计费DeepSeek的token价格明显更低日常写脚本、改代码这种小任务单次花费几乎可以忽略。每个人用量不同我的建议是先小额充值跑一周统计下每天消耗多少token心里有数之后再定长期方案。另一个实操建议把DeepSeek的base_url和Key统一放在环境变量里管理配置文件里只写名字和env_key。这样换环境部署时不用改toml只改环境变量就行。5.5 遇到“模型不支持”的报错别慌接第三方模型时常见一个报错大意是“the gpt-5.6-sol model is not supported when using codex with a ...”翻译成人话就是你让Codex用的模型名在当前的模型服务方里根本不存在。原因往往是配置里的model抄错了或者网上看到的配置里写了个臆造的模型名。解决思路就三步第一确认provider的base_url对应的服务商实际提供哪些模型名第二把配置或命令行里的--model改成真实存在的模型名第三注意wire_api要和服务商支持的接口匹配。所有报错信息里模型名是最值得逐字检查的大小写和连字符都不能错。6. 实战演示用Codex从零完成一个小工具6.1 一个典型的“交给Codex”任务理论讲再多不如跑一个真实任务。假设你是一个刚装好Codex、接好DeepSeek的零基础用户我们要让它在当前目录下完成这样一个需求写一个Python脚本把当前目录下所有的.png图片按时间顺序批量重命名为photo_0001.png、photo_0002.png这样的格式同时生成一个包含新旧文件名对应关系的JSON清单。这个需求很典型它涉及文件扫描、排序、重命名、写文件、生成文档正好能体现Codex的Agent能力。6.2 提示词怎么写更靠谱很多人让Codex干活不理想问题大多出在提示词上。我给一个适用于所有Codex场景的通用写法背景加目标加约束。背景告诉它在哪里干活目标说清楚最终要什么约束说明哪些事不能做。上面的需求可以这样描述codex exec 在当前目录下写一个Python脚本扫描当前目录所有.png文件按修改时间排序后重命名为photo_0001.png、photo_0002.png这样的连续编号同时生成rename_map.json里面记录每个文件旧名字到新名字的对应关系。注意不要改动其他类型的文件脚本要能在Python 3环境下直接运行。如果你想让Codex更谨慎可以在最后加一句“先给我脚本内容不要直接执行重命名”等你看过脚本再让它跑。6.3 分步观察与结果确认执行上面的命令后你会看到Codex先列出计划然后创建脚本文件、检查文件列表、运行脚本、打印结果。重点关注两个时刻写文件前有没有展示脚本内容运行前有没有让你确认。如果之前加了“先不要执行”那就先自己把脚本打开看一遍确认逻辑没问题后再告诉它“现在运行脚本”。运行完检查三样东西目录里是不是出现了photo开头的文件rename_map.json是不是只包含png条目非png文件有没有被动过。只要这三样都对任务就算完成。这整个流程走下来你会发现Codex不是简单聊天而是真的在替你操作文件系统所以执行前的确认是对自己负责。复杂任务建议拆成两到三步让Codex做完一步再下一步比一口气给一大段需求更容易得到靠谱结果。7. 常见问题速查表与避坑心得7.1 网络请求失败的排查思路Codex使用中最高频的报错就是请求失败类。根据社区反馈有一类报错开头类似“cc switch local ... failed while handling codex endpoint /responses”很多人看到一大段英文就慌了。从我的实际排查经验看这类错误的根因基本都在网络链路本地环境访问模型服务商接口失败请求根本没发出去。排查顺序总结为四步第一步先用curl单独测试接口连通性比如curl https://api.deepseek.com/v1/models看能不能通第二步确认当前网络是否有特别限制比如公司网络、公共WiFi的防火墙策略第三步重启Codex进程有时候是长连接异常第四步升级到最新版Codex这类网络修复代码更新频繁。注意这四步都是在检查网络本身不要想当然去改什么“绕过访问”的配置那些操作既不稳定也没有必要。7.2 配置文件报错unrecognized configuration setting如果启动或执行命令时看到“codex is ignoring 1 unrecognized configuration setting. check for typos or ...”意思是config.toml里有一个不认识的配置项。常见两个原因你抄了网上老版本的配置里面某个键在新版本被改名或删除了或者你手滑打错了键名。处理方式打开config.toml把不是核心的键前面加#注释掉再启动Codex逐条排除。看到这个提示时Codex其实还在运行只是忽略了你配的这项表现就是某项功能不生效。排查到问题键后要么去掉要么换成新版本支持的写法。7.3 Windows环境设置未完成的最终方案这个问题我在2.5节详细说过这里补充一个心态建议不要在原生Windows环境里反复重试安装把精力放到WSL 2上一次配好长久省心。配好WSL后Codex所有操作都和Linux一致教程里任何命令都能直接跑。7.4 MCP扩展与插件生态Codex已经支持MCP也就是模型上下文协议。看到“插件”相关问题的朋友其实很多问的就是MCP服务器。简单理解MCP是给Codex扩展“外部工具”的标准接口比如让它能操作数据库、访问浏览器、读本地文档都可以通过配置MCP Server实现。在config.toml里增加一个[某个MCP服务器名]的配置段指定command和argsCodex启动时就会自动加载它。新手阶段不用急着配MCP先把核心玩法跑通等需要外接工具时再回来研究官方仓库的文档里有完整的server列表和示例。另外Codex官方在VS Code里也发布了同名扩展插件装好后能在编辑器侧边栏里用同一套Codex能力和CLI共享配置。喜欢图形界面的朋友可以先从插件入手配置文件、登录凭证都是同一套不用重复配置。最后再分享一点我自己的体会。Codex这种工具用熟了以后最大的价值不是替你写代码而是把你从执行细节里解放出来你不用再手敲一长串shell命令去做文件批处理不用为了找一个配置项翻遍整个项目只要把任务说清楚剩下的执行交给它你只需要审查结果。我踩过最大的坑是早期太相信它的自动操作放着默认的workspace-write不用非要去开dangerous模式结果它把我临时目录里没提交的文件清理了。从那以后我的原则就两条默认沙箱级别不动执行敏感操作前一定让它先给我看命令。还有一个小技巧让Codex先解释再动手比直接让它闷头改代码更容易定位问题。这套组合我用了很久踩过坑之后基本没再翻车希望对你也管用。