1. Codex 跑久了就报 /bin/bash 启动失败问题到底出在哪如果你也在 WSL 里用 Codex 做长时间编码任务大概率遇到过这个场景前半小时一切正常任务跑到一半突然抛出一句/bin/bash 启动失败然后整个会话就卡死或者直接退出。我第一次遇到时以为是 Codex 本身崩了重启一遍又能跑但跑久了照样复现非常影响节奏。这个报错的核心其实不在 Codex而在 WSL 的进程与内存回收机制。Codex 在执行任务时会频繁通过/bin/bash拉起子进程来跑命令、读文件、执行脚本而 WSL2 是一个轻量虚拟机它的内存回收策略默认比较激进。当 Codex 长时间运行、内存占用持续升高后WSL 可能把 bash 相关的进程或内存页回收掉下一次 Codex 再想 fork 一个/bin/bash时就失败了。所以排查方向应该分两层一层是 WSL 侧的资源与版本问题另一层是 Codex 侧的 endpoint 与认证配置。这篇就按我实际踩坑的顺序把.wslconfig资源限制、wsl --update版本状态、Codex 的auth.json与 endpoint 检查串起来讲一遍最后给出把 Codex 通道切到 TaoToken 的完整配置和验证动作。适合在 WSL 里长期跑 Codex、被这个报错反复打断的人跟做。2. 先修 WSL.wslconfig 内存回收与 wsl --update 版本排查WSL2 默认会动态占用宿主内存但它的autoMemoryReclaim在旧版本里行为不稳定长时间高负载下容易出现内存页被回收、进程句柄失效的情况表现就是子进程启动失败。解决思路有两个更新 WSL 到较新版本以及用.wslconfig显式约束内存和回收策略。先看版本。打开 PowerShell不是 WSL 内部执行wsl --version如果输出的 WSL 版本比较老或者提示命令不存在直接更新wsl --update更新完成后建议再跑一次wsl --version确认版本号变化。更新能拿到更稳定的内存回收实现这是最省事的一步。接着做资源约束。在 Windows 用户目录下创建或编辑.wslconfig路径是C:\Users\你的用户名\.wslconfig。写入以下内容[wsl2] memory12GB swap8GB autoMemoryReclaimgradual vmIdleTimeout60000几个参数的作用memory12GB限制 WSL 最多用 12GB 内存避免它无限膨胀后被系统强制回收swap8GB给足交换空间内存压力大时有缓冲autoMemoryReclaimgradual让内存回收变成渐进式而不是一次性粗暴回收这对 Codex 这种持续拉起子进程的场景很关键vmIdleTimeout60000设置空闲超时减少不必要的虚拟机休眠。保存后必须彻底重启 WSL 才生效。在 PowerShell 里执行wsl --shutdown然后重新打开你的 WSL 终端。想确认配置是否被读取可以在 WSL 内执行free -h看 total 内存是否接近你设置的 12GB。如果还是宿主全部内存说明.wslconfig没生效检查文件名是不是写成了.wslconfig.txtWindows 默认隐藏扩展名这个坑很常见。另外长时间运行后想看看是不是 bash 进程堆积可以在 WSL 里执行ps aux | grep -c bash如果这个数字异常大说明有僵尸或残留进程配合前面的内存回收配置能明显缓解。3. 把 Codex 通道切到 TaoTokenauth.json 与 endpoint 配置WSL 侧修好后还要确认 Codex 的请求通道是稳定的。Codex 默认走官方 endpoint网络波动或认证过期时也可能表现为子进程异常退出。把 endpoint 切到 TaoToken 可以统一管理 Key 和模型配置集中在auth.json里。先拿到 API Key。访问 TaoToken 的 API Keys 页面创建https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_wsl_bash_failutm_campaignrewrite创建后复制 Key然后找到 Codex 的配置目录。在 WSL 里通常是~/.codex/编辑auth.json{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api }注意 Base URL 用https://taotoken.net/api不要带 UTM 参数那是给页面跳转用的接口地址保持干净。如果你用的是支持自定义 provider 的配置形式也可以写成 TOML[model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [profiles.default] model_provider taotoken model claude-sonnet-4-5三件套要写全Base URL 是https://taotoken.net/apiKey 是你在 API Keys 页面创建的那串Model ID 按你实际要用的填比如claude-sonnet-4-5或gpt-5这类。缺任何一个都会导致请求失败而失败信息有时会被 WSL 的进程报错盖住让你误以为是 bash 的问题。配置改完后同样建议wsl --shutdown重启一次让 Codex 重新读取配置。这一步和 WSL 修复叠加能排除掉大部分「跑久了就崩」的情况。4. 验证请求一次重启后的成功结果确认配置改完别急着跑长任务先做一次最小验证确认通道通了、bash 也能正常拉起。第一步在 WSL 里确认环境变量或配置文件被读取cat ~/.codex/auth.json看 Key 和 Base URL 是否正确写入没有多余空格或换行。第二步发一个最小请求测试 endpoint。如果你用 curl 验证curl https://taotoken.net/api/v1/models \ -H Authorization: Bearer sk-你的TaoToken密钥返回模型列表就说明 Key 和通道没问题。如果返回 401说明 Key 错了或没生效回到上一步检查。第三步启动 Codex 跑一个短任务比如让它读一个文件并输出内容。观察是否正常调用/bin/bash。我实测下来修完.wslconfig并切到 TaoToken 后连续跑一两个小时不再出现 bash 启动失败。第四步跑完后检查进程数ps aux | grep -c bash数字应该回落到正常范围不会持续堆积。如果还是很高说明有任务没正常退出需要看 Codex 的日志。想直接对话验证模型是否可用可以走模型对话页面https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_wsl_bash_failutm_campaignrewrite在这里发一条消息能正常返回就说明账号和通道都是通的再回到 Codex 里跑任务就放心了。5. 常见报错排查401、local proxy failed 与 reading choices即使按上面配好了还是可能撞到几个典型报错。这里按我遇到过的顺序列一下对照。401 Unauthorized最常见。原因通常是auth.json里的 Key 写错、过期或者 Base URL 带了多余路径。检查 Key 是否从 API Keys 页面完整复制Base URL 是否严格是https://taotoken.net/api。如果用了环境变量方式确认TAOTOKEN_API_KEY在当前 shell 里echo得出来。local proxy failed / connection refused这个多半是 WSL 网络或代理残留导致。先确认没有残留的代理环境变量env | grep -i proxy如果有输出说明 shell 里还留着代理设置清掉再试。WSL 的网络在wsl --shutdown后会重建重启一次通常能解决。reading choices 相关报错这类通常是响应体解析失败根源可能是 endpoint 返回了非预期内容比如被中间层拦截或返回了 HTML 错误页。用第 4 节的 curl 命令直接打接口看返回的是 JSON 还是 HTML。如果是 HTML说明请求没到真正的 API检查 Base URL 拼写。OAuth 相关报错如果你之前用官方登录方式认证过auth.json里可能残留 OAuth token和新的 API Key 冲突。把auth.json里旧的 OAuth 字段清掉只保留OPENAI_API_KEY和OPENAI_BASE_URL。bash 启动失败依旧复现回到第 2 节确认.wslconfig真的生效free -h看内存并确认wsl --update后版本已更新。两个都做了还不行把autoMemoryReclaim从gradual改成disabled试一次排除回收策略本身的干扰。排查时建议一次只改一个变量改完就wsl --shutdown重启验证不然多个改动叠加出了问题很难定位是哪一个引起的。6. 长期在 WSL 跑 Codex 的通道与配置建议如果你打算长期在 WSL 里用 Codex 做编码或 Agent 任务建议把通道固定下来别每次临时改。TaoToken 的 Coding Plan 适合这种持续调用的场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_wsl_bash_failutm_campaignrewrite接入文档里有各客户端的完整配置示例遇到不确定的字段可以对照https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_wsl_bash_failutm_campaignrewrite控制台可以随时查看用量和 Key 状态https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentcodex_wsl_bash_failutm_campaignrewrite我的习惯是.wslconfig配好后基本不动Codex 的auth.json里 Key 和 Base URL 写死模型 ID 按任务切换。每次大版本更新 WSL 或 Codex 后跑一次第 4 节的验证流程确认通道和 bash 都正常再开始长任务。这样即使中途出问题也能快速判断是 WSL 侧还是通道侧不用从头排查。