Codex 安装与登录：macOS、Linux 和 Windows 从零开始
安装就三步：跑一条命令、进项目目录运行 codex、选登录方式。四种装法里安装脚本最直接，npm 和 Homebrew 适合已有这套工具链的人，升级方式各不相同。装完先别急着干活，用 /status 看一眼模型、沙箱和审批这三项，它们决定了它接下来能做什么。另外要分清三种「连不上」：外部网络、账号资格、沙箱自己关着的网络，排查方向完全不同。
Codex 的安装比想象中简单，三步：
codex但装完之后建议多做一步：在会话里敲 /status，看一眼当前用的什么模型、沙箱是哪一档、审批策略是什么。
这三项决定了它接下来能做什么、不能做什么。不看的话，很容易出现两种情况——要么它什么都做不了，你以为是装坏了；要么它比你以为的能做得多。
需要的东西不多：
最后两条是真正的门槛，装的过程本身没有难度。
curl -fsSL https://chatgpt.com/codex/install.sh | sh
最直接的一条路，没有前置依赖，装完就能用。
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
前面那段 -ExecutionPolicy ByPass 是为了绕过 PowerShell 默认的脚本执行限制，不加的话可能会被拦下来。
npm install -g @openai/codex
机器上已经有 Node 和 npm 的，这条最顺手。
有一条通用建议：不要用 sudo npm install -g。全局安装用 sudo 容易带来权限和安全问题，遇到权限报错应该去配置 npm 的全局目录，而不是加 sudo。
brew install --cask codex
macOS 上习惯用 brew 管软件的可以走这条。
| 情况 | 建议 |
|---|---|
| 没有特别偏好 | 安装脚本 |
| 机器上已经有 Node 和 npm | npm |
| macOS 且习惯用 brew 管软件 | Homebrew |
| 官方地址下载不动 | 先试 npm |
最后一条对国内网络环境有用：安装脚本走 chatgpt.com，npm 走 npm 的包仓库，两条路径的域名完全不同，一条不通可以试另一条，npm 还能换成国内镜像源。
升级方式跟着装法走，不能混：
| 装法 | 升级命令 |
|---|---|
| 安装脚本（macOS/Linux） | 重新跑一遍安装命令 |
| 安装脚本（Windows） | 重新跑一遍 PowerShell 命令 |
| npm | npm install -g @openai/codex |
| Homebrew | brew upgrade --cask codex |
注意 Homebrew 是 upgrade 不是 install，另外三种都是重跑安装命令。
如果不确定自己当初是怎么装的，最简单的办法是重新跑一遍安装脚本——它会处理好覆盖安装。
进一个项目目录再启动，不要在家目录裸跑：
mkdir codex-test
cd codex-test
codex
为什么强调进目录：Codex 的沙箱默认是「只能写当前工作区」，而工作区就是你启动它的那个目录。在家目录启动，等于把整个家目录设成了可写范围。
这是它和很多工具不一样的地方，也是最值得从第一天就养成的习惯：每类活一个目录，进目录再启动。
启动后会让你选登录方式，用 ChatGPT 账号登录是最常见的一种，也可以用 API Key。ChatGPT 的付费计划本身包含 Codex 的用量，不需要额外配置。
登录完可以先让它做点无害的事，比如让它看一眼当前目录里有什么，确认整条链路通了。
在会话里敲：
/status
重点看三项：
/modelworkspace-write，也就是只能改当前目录on-request，越界和联网时会问你还有一个命令值得早点知道：
/permissions
它用来设定哪些操作不用问就能做。刚开始建议先别放宽，等你摸清它的行为再说。
其他几个常用的：
/init：在当前目录生成一份 AGENTS.md 骨架，用来写你们自己的规则/model：切换模型/diff：查看它改了哪些东西/mcp：看有哪些外部工具可用登录成功不等于能干活。建议第一天就跑一个贴近实际的小任务，把「账号能用、能读到文件、能写出成果」这三件事一次验完。
准备一个目录，放一份商品导出：
mkdir codex-ecommerce-test
cd codex-ecommerce-test
mkdir data
# 把一份商品 CSV 放进 data/
codex
然后给它一个具体的活：
读取 data/ 目录下的商品 CSV，统计产品数量、价格区间和各价格段的分布，生成一份 Markdown 报告写到 report.md。不要修改原始文件。
这个任务有几个地方是故意这么设计的：
跑完看三件事：
report.md 生成了没有第二条最重要。第一次一定要手工核对，因为如果它把列对应错了，后面所有分析都是错的，而报告本身看起来会很正常。
如果中途它请求审批，说明有动作越过了当前沙箱的边界。看清楚它要干什么再决定，这也是熟悉审批机制的好机会。
终端不是唯一的用法。
IDE 扩展：VS Code 和兼容的编辑器有 Codex 扩展，可以在编辑器里侧边用，好处是它默认就看得到你当前打开的文件，省掉重新描述背景。
云端任务：耗时长的活可以交给云端跑，在编辑器里看进度、预览改动、把结果应用到本地。适合那种「跑一小时」的批量任务，不用一直占着本机。
ChatGPT 里的 Codex：付费计划里可以直接用。
对跨境运营来说，建议还是从 CLI 开始。原因是运营的活基本都围绕本地文件：导出的报表、整理好的资料、生成的报告。CLI 直接在目录里干活，路径最短，沙箱边界也最清楚。
这一节写给直连不畅的环境。要点是先分清四件事，它们的排查方向完全不同，混在一起会白折腾很久。
这是最根本的一层，也是配代理解决不了的一层。
Codex 需要能用的 ChatGPT 付费计划（Plus、Pro、Business、Edu、Enterprise）或者 API Key。而 OpenAI 对可用的国家和地区有明确名单，ChatGPT 和 API 各有一份，中国大陆不在名单内。
官方还有一句明确的提醒：在名单之外的地区访问或提供访问，可能导致账号被封停。
所以对大陆读者，这一层要先想清楚。如果账号这关过不去，装上了也跑不起来，往下折腾安装和代理都没有意义。后面「还有一条路」那一小节讲不依赖 OpenAI 账号的做法。
这是纯下载问题，和账号无关。
安装脚本走 chatgpt.com，npm 走 npm 的包仓库，两条路径域名完全不同。一条不通试另一条，npm 还可以换成国内镜像源。
| 装法 | 要访问 |
|---|---|
| 安装脚本（macOS/Linux/Windows） | chatgpt.com |
| npm | npm 包仓库 |
| Homebrew | Homebrew 的源 |
判断方法很简单：如果 curl 那条命令下不动，直接换 npm 试。
这是运行时的网络问题。Codex 要连 OpenAI 的服务才能工作。
如果公司或本地有 HTTP 代理，标准的代理环境变量通常是可用的，具体支持哪些变量以官方文档为准。配完之后进会话用 /status 确认。
这一条最容易被误判成前一条，但完全是两回事。
**Codex 的沙箱默认就把网络关了。**所以如果它本身能正常对话、只是它跑的命令连不上网，那不是你的网络问题，是沙箱那一层的设定。
判断方法：
打开的方式是显式声明：
codex -c 'sandbox_workspace_write.network_access=true'
建议临时开、用完就算，别写进全局配置。沙箱那篇会讲为什么。
按这个顺序走，能省最多时间：
codex 命令装上了没有 —— 换装法试如果第一件事（账号）过不去，Codex 还有一条不依赖 OpenAI 账号的路径。
Codex 的配置里可以指定自己的模型服务商，而且内置了三个服务商 ID：openai、ollama、lmstudio。后两个是本地模型的运行环境——也就是说，跑本地模型是官方支持的一条路径，不需要自己拼配置。
这条路对两类人有用：
也可以指向自建或第三方的服务地址，写法是在配置里加一个 model_providers 条目，填服务地址和密钥所在的环境变量。
但这里有个必须提前知道的限制：Codex 的服务商协议目前只支持一种（wire_api = "responses"）。实际含义是，不是随便一个「OpenAI 兼容」的第三方地址都能直接接上，对方的接口得讲这套协议才行。接之前先确认这一点，能省掉大量「配好了但一直报错」的排查。
这也意味着，比起某些同类工具，Codex 接国内第三方服务的门槛更高一些，而本地模型反而是更顺的一条路。
代价要说清楚：本地模型的能力和云端有差距，多步任务的规划、长上下文的处理、工具调用的准确度都会打折。所以合理的用法不是全部本地化，而是按数据敏感度分流——常规分析用能用的云端服务，涉及敏感数据的那部分用本地。
具体的配置写法在下一篇。
| 症状 | 优先检查 |
|---|---|
codex: command not found |
关掉终端重新开一个；确认安装目录进了 PATH |
| PowerShell 里脚本被拦下来 | 安装命令里的 -ExecutionPolicy ByPass 有没有带上 |
| 启动后一直要求登录 | 账号是否有可用的付费计划或有效的 API Key |
| 它说没有权限改文件 | 看 /status 里的沙箱档位，以及你是在哪个目录启动的 |
| 它跑的命令连不上网 | 沙箱的网络默认关闭，需要显式打开 |
| 它想改工作区外的文件 | 这是设计如此，会请求审批。要么批准，要么换个目录启动 |
| npm 装完找不到命令 | 检查 npm 全局目录是否在 PATH 里 |
| 不确定当初怎么装的 | 重跑一遍安装脚本 |
codex 能启动/status 能看到模型、沙箱、审批三项六条都过了，再往下走。最后一条尤其值得做——它同时验证了三件事：账号能用、它能读到本地文件、它能写出成果物。
下一篇讲配置文件：config.toml 放在哪、能配什么、项目级怎么覆盖用户级，以及为什么建议给不同类型的活准备不同的配置，而不是写一套全局的。
作者
大阪烧鸟
大阪烧鸟，关注 AI 在跨境电商运营中的实际应用、Shopify 独立站与日本商业观察，偏爱把复杂问题拆成可执行的方法。
