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.json700表示只有你自己能进这个目录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看它到底在找哪个路径需要装 stracestrace -f -e traceopenat codex print hello 21 | 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不要带尾部斜杠也不要在后面手动加/v1codex 会自己拼。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 各验证一次。照着做登录状态基本能稳定下来。 
长河君 · 2026/10/7 19:29:25 · 阅读 1.2k 解决WSL中无法登录codex（亲测有效）：把auth.json改到TaoToken
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.json700表示只有你自己能进这个目录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看它到底在找哪个路径需要装 stracestrace -f -e traceopenat codex print hello 21 | 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不要带尾部斜杠也不要在后面手动加/v1codex 会自己拼。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 各验证一次。照着做登录状态基本能稳定下来。