企业官网建设流程全解析

1. WSL 里 codex 登录失败到底卡在哪

在 WSL 里跑 codex 这类命令行 AI 编码工具，最让人抓狂的不是模型答得不好，而是压根登录不上。你敲完命令，终端要么转圈半天没反应，要么直接甩一句认证失败，要么浏览器回调地址打不开。我一开始以为是网络问题，折腾了半天网络模式，最后发现根子其实在auth.json这个认证文件上——它的路径、权限、以及 codex 读取配置的顺序，在 WSL 和纯 Linux、纯 Windows 下都不一样。

先说清楚 codex 是什么、能做什么、适合谁。codex 是 OpenAI 推出的命令行编码代理工具，可以在终端里直接读你的项目文件、改代码、跑命令，适合习惯在命令行里干活、又想让 AI 帮忙写代码和排查问题的开发者。它需要先完成一次认证，把凭证落到本地一个叫auth.json的文件里，后续每次启动都从这个文件读登录态。

问题就出在这个文件上。WSL 是个混合环境：你的家目录在 Linux 侧（比如/home/yourname），但 Windows 侧还有一套用户目录（C:\Users\yourname）。codex 在不同安装方式下，可能去 Linux 家目录找auth.json，也可能去 Windows 用户目录找，甚至因为环境变量HOME被改过而跑到一个你根本没想到的地方。结果就是：你在 A 路径登录成功了，codex 却去 B 路径读，自然读不到，于是报「未登录」。

还有一种常见情况是权限。WSL 挂载 Windows 盘符（/mnt/c/...）时，默认权限是 777 或者被metadata选项影响，codex 出于安全考虑会拒绝读取权限过宽的文件，于是你明明把auth.json放对了地方，它还是说认证无效。这个坑特别隐蔽，因为文件确实存在，内容也没错，就是权限不对。

再就是配置读取顺序。codex 会按一定优先级找配置：环境变量指定的路径 > 当前工作目录 > 用户家目录。如果你在项目里跑 codex，而项目目录下恰好有个旧的auth.json或者.codex目录，它会优先用那个，导致你以为在用全局登录态，其实用的是项目里的旧凭证。

所以这篇的思路很明确：不纠结网络模式那些外围问题，直接把auth.json的路径、权限、读取顺序这三件事理顺，让 codex 在 WSL 里稳定认到你的登录态。下面我会给出可复制的配置片段和逐步验证命令，照着做基本能一次过。

2. 用 TaoToken 承接 codex 的认证配置

在动手改auth.json之前，得先有一个稳定的接入端点。codex 默认连的是官方端点，但在国内网络环境下，直连经常超时或者握手失败，这也是很多人「登录不上」的直接原因——不是凭证错，是请求根本没发出去。我现在的做法是用 TaoToken 作为接入层，把 codex 的 Base URL 指过去，认证和请求都走这条通道，稳定很多。

TaoToken 在这里扮演的角色是「统一的模型接入网关」。你不需要改 codex 的源码，也不用装额外的插件，只要把它的 Base URL 和 API Key 填进配置，codex 就会把请求发到 TaoToken，由它转发到对应的模型。对 codex 来说，它只是换了个 endpoint，其他逻辑不变。这样做的好处是：认证文件只需要存一份 TaoToken 的 Key，不用来回切换官方凭证；而且端点固定，不会因为网络波动导致登录态失效。

具体要准备两样东西：Base URL 和 API Key。Base URL 用https://taotoken.net/api，注意这个地址不带任何查询参数，直接填就行。API Key 需要你去控制台生成，路径是登录后进「API Keys」页面新建一个。生成后先复制保存，因为页面刷新后完整 Key 就不再显示了。

这里有个细节要注意：codex 的配置里，Base URL 和 API Key 是分开填的，Base URL 决定请求发到哪，API Key 决定身份。很多人只改了 Base URL 忘了换 Key，结果请求发到 TaoToken 但带着官方 Key，自然 401。所以两样必须配套。

如果你还没生成 Key，可以先去控制台把 Key 建好。生成 Key 的入口在控制台的 API Keys 页面，点新建、起个名字（比如wsl-codex）、复制保存。这个 Key 后面要写进auth.json或者环境变量，所以别弄丢。

另外，如果你打算长期在 WSL 里用 codex 做编码和 Agent 任务，可以考虑 Coding Plan，它比按量计费更适合高频使用场景，具体可以在站内看套餐说明。但不管用哪种计费方式，接入的 Base URL 和认证方式是一样的，先把连通性跑通再说。

准备好这两样之后，下一步就是把它写进 codex 能读到的配置文件里。这里要特别小心路径问题，因为 WSL 的家目录和 Windows 用户目录是两套，写错地方 codex 就找不到。下一节我会给出完整的auth.json片段和放置位置。

3. 可复制的 auth.json 配置与路径

这一节是核心，直接给可复制的内容。codex 的认证文件叫auth.json，默认放在用户家目录下的.codex目录里，也就是~/.codex/auth.json。在 WSL 里，~展开后是/home/你的用户名，不是/mnt/c/Users/...，这点必须先确认。

先确认你的家目录和当前用户：

echo $HOME whoami

正常应该输出类似/home/yourname和yourname。如果$HOME指向了/mnt/c/...或者别的奇怪路径，说明环境变量被改过，后面 codex 找文件就会跑偏，需要先修正。

确认无误后，创建目录并写入配置：

mkdir -p ~/.codex cat > ~/.codex/auth.json <<'EOF' { "OPENAI_API_KEY": "sk-你的TaoToken密钥", "OPENAI_BASE_URL": "https://taotoken.net/api" } EOF

把sk-你的TaoToken密钥替换成你在控制台生成的那串 Key。注意 JSON 格式很严格：键和值都要用双引号，最后一项后面不能有多余逗号，否则 codex 解析会直接报错。

写完之后立刻修权限。这是 WSL 里最容易翻车的一步：

chmod 700 ~/.codex chmod 600 ~/.codex/auth.json

700表示只有你自己能进这个目录，600表示只有你自己能读写这个文件。codex 对凭证文件的权限比较敏感，如果权限过宽（比如 644 或 777），它可能拒绝读取，报「insecure permissions」之类的错。尤其在/mnt/c下，WSL 默认给的权限往往不对，所以强烈建议把auth.json放在 Linux 家目录，而不是 Windows 盘符里。

如果你确实需要放在 Windows 侧（比如想和 Windows 版 codex 共用），那路径会变成/mnt/c/Users/你的Windows用户名/.codex/auth.json，但权限问题会更麻烦，需要在/etc/wsl.conf里开启 metadata 支持，还要处理 drvfs 挂载选项。除非有明确需求，否则不推荐，直接放 Linux 家目录最省事。

配置写好后，可以用一个命令快速校验 JSON 是否合法：

python3 -m json.tool ~/.codex/auth.json

如果输出格式化后的 JSON，说明格式没问题；如果报错，就回去检查引号和逗号。这一步能帮你排除掉一大半「配置看起来对但就是登录不上」的情况。

还有一点关于读取顺序：codex 启动时会先看环境变量OPENAI_API_KEY和OPENAI_BASE_URL，如果这两个变量存在，会优先用环境变量，而不是auth.json。所以如果你之前在.bashrc或.zshrc里 export 过旧的 Key，它会覆盖文件里的配置。检查一下：

env | grep -i openai

如果有输出，说明环境变量在起作用，要么更新它，要么删掉让它回退到读文件。这个顺序问题很隐蔽，很多人改了auth.json却没生效，就是被环境变量截胡了。

4. 验证请求与确认登录状态

配置写完不等于登录成功，必须实际发一次请求确认。codex 本身有登录状态检查命令，但不同版本命令略有差异，最稳的办法是直接跑一次最小任务，看它能不能正常返回。

先确认 codex 能读到你的配置。启动 codex 后，它会打印当前使用的 endpoint 和认证来源（部分版本会显示）。如果看不到，可以用一个简单的对话请求测试：

codex "print hello"

如果配置正确，它会返回模型输出；如果认证失败，会报 401 或「invalid api key」。这一步能直接区分是「配置没读到」还是「Key 无效」。

想更精确地验证端点连通性，可以绕过 codex，直接用 curl 打一次 TaoToken 的接口：

curl -sS https://taotoken.net/api/v1/models \ -H "Authorization: Bearer sk-你的TaoToken密钥" \ | head -c 500

如果返回一串模型列表的 JSON，说明 Base URL 和 Key 都没问题，网络也通。如果返回 401，说明 Key 错了或者没带上；如果连接超时，说明网络层有问题，这时候再回头查 WSL 的网络模式。注意这个命令里的 URL 是https://taotoken.net/api/v1/models，/api是基础路径，/v1/models是具体接口，别拼错。

curl 通了之后，再回到 codex 跑一次真实任务，比如让它读一个文件：

codex "read README.md and summarize it"

能正常返回摘要，就说明登录态完全正常了。这时候你可以检查一下auth.json有没有被 codex 改写（有些版本登录成功后会更新文件里的 token 字段），如果被改写且权限变了，重新chmod 600一下。

还有一个验证点是重启后的持久性。关掉终端，重新开一个 WSL 会话，再跑一次codex "print hello"。如果还能正常返回，说明配置是持久的，不是靠当前会话的环境变量撑着。这一步很重要，因为很多人当时能用，重启就失效，就是配置没落盘或者被环境变量临时顶上了。

如果验证过程中 codex 提示找不到配置文件，可以用strace看它到底在找哪个路径（需要装 strace）：

strace -f -e trace=openat codex "print hello" 2>&1 | grep auth.json

输出会显示它尝试打开的auth.json完整路径，对照一下是不是你写的那份。这个办法能彻底定位路径不一致的问题，比猜要快得多。

5. 常见报错逐条排查

这一节把 WSL 里 codex 登录最常撞到的几个报错列出来，对照着查。

401 Unauthorized / invalid api key：最常见。先确认auth.json里的 Key 和你在控制台生成的一致，注意有没有多余空格或换行。然后检查环境变量有没有覆盖：env | grep -i openai，如果有旧的OPENAI_API_KEY，它优先级高于文件，会带着旧 Key 发请求。解决办法是unset OPENAI_API_KEY或者更新它。还有一种可能是 Key 被复制时截断了，重新生成一个再试。

local proxy failed / connection refused：这个报错说明 codex 尝试走本地代理但连不上。WSL 里如果之前配过HTTP_PROXY或HTTPS_PROXY指向127.0.0.1:某端口，而那个代理在 WSL 侧并不存在，就会这样。检查env | grep -i proxy，把不需要的代理变量清掉。注意 WSL2 的127.0.0.1和 Windows 的127.0.0.1不是同一个，Windows 上的代理在 WSL 里默认访问不到，除非用 mirrored 网络模式或者填 Windows 主机 IP。

reading choices / unexpected end of JSON input：这个通常不是认证问题，而是响应体不完整或者返回了非 JSON 内容。常见原因是 Base URL 拼错，比如漏了/api或者多加了/v1，导致请求打到了错误路径，返回了 HTML 错误页。核对一下OPENAI_BASE_URL是不是https://taotoken.net/api，不要带尾部斜杠，也不要在后面手动加/v1，codex 会自己拼。

OAuth / browser callback failed：如果你用的是需要浏览器回调的登录方式，在 WSL 里浏览器打不开或者回调地址localhost指向不对，就会卡住。WSL2 默认 NAT 模式下，Windows 浏览器访问localhost不一定能回到 WSL 里的服务。解决办法是改用 API Key 方式（也就是本文的auth.json方案），绕开浏览器回调；或者把网络模式调成 mirrored，让 localhost 互通。但既然我们已经用 Key 认证，直接走文件配置最省心。

permission denied / insecure file permissions：前面提过，auth.json权限太宽。执行chmod 600 ~/.codex/auth.json和chmod 700 ~/.codex。如果文件在/mnt/c下，chmod 可能不生效，需要改/etc/wsl.conf加[automount] options = "metadata"，然后wsl --shutdown重启。但更简单的办法是把文件挪到 Linux 家目录。

配置改了不生效：九成是环境变量覆盖，或者 codex 读的是项目目录下的局部配置。检查当前目录有没有.codex文件夹或auth.json，有的话它会优先用局部的。另外确认你改的是~/.codex/auth.json而不是~/.config/codex/auth.json，不同版本默认路径可能不同，用第 4 节的strace方法确认实际读取路径最靠谱。

排查顺序建议：先 curl 测端点通不通，再查环境变量有没有覆盖，再看文件权限，最后用 strace 确认路径。按这个顺序走，基本不会绕弯路。

6. 把认证固定下来的几个实用做法

配置跑通之后，还有几件事能让它更稳。第一是把auth.json的备份留一份，但别明文扔在项目里，可以放到一个只有你可读的目录，或者用密码管理器存 Key，需要时再写回文件。第二是如果你在多台机器或多套 WSL 发行版里用 codex，每套都要单独配一份auth.json，因为它们家目录是隔离的，不会自动同步。

第三，如果你经常重建 WSL 或者换发行版，可以把配置写进一个初始化脚本，比如setup-codex.sh，里面包含创建目录、写文件、chmod 三步，重建后跑一次就恢复。脚本里 Key 可以用环境变量传入，避免硬编码。

第四，关于长期使用，如果你发现自己每天都在跑 codex 做编码任务，按量计费可能不如 Coding Plan 划算，可以去站内看看套餐对比。但无论哪种，接入方式不变，还是 Base URL 加 Key 这套。

最后提醒一句：auth.json里存的是明文 Key，任何能读这个文件的进程都能拿到你的凭证。所以权限一定要收紧，别把它提交到 git，也别放在共享目录里。WSL 的家目录默认只有你自己能访问，放这里是最安全的。

到这里，WSL 里 codex 登录失败的路径、权限、读取顺序三个坑就都覆盖了。核心就一句话：把auth.json放对位置、给对权限、确认没有环境变量截胡，然后用 curl 和 codex 各验证一次。照着做，登录状态基本能稳定下来。