Linux 上把 Codex CLI 装好npm 全局安装没报错ripgrep 和 bubblewrap 也都在结果一跑codex doctor最后一行给你来一个✗ Auth: not authenticated。这个报错比“命令找不到”更让人烦因为二进制已经在了依赖也像齐了偏偏认证没过去。第一次在 Debian 12 上看到这个输出时我以为只是OPENAI_API_KEY没 export后来发现 systemd 服务里只写一个EnvironmentOPENAI_API_KEY...还不够因为 Codex CLI 默认还在往它熟悉的端点发认证请求。把认证环节改到 TaoToken 提供的统一通道问题会清楚很多先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建 Key再把 Codex CLI 的 Base URL 填成 https://taotoken.net/api。这里要特别记住末尾不要加/v1也不要填官网地址。下面按 Linux 安装 Codex CLI 的主路径走一遍从codex doctor的报错、~/.codex/config.toml、systemd 服务到验证和排障尽量让每一步都能直接复制。1. codex doctor 报 ✗ Auth: not authenticated 时先看什么codex doctor的输出一般会分几块依赖是否存在、沙箱是否可用、认证能不能过。很多人只看到最后那个红色叉就急着重新npm install -g其实安装层大概率没问题。先往上看几行确认ripgrep、bubblewrap、Node 版本这些是不是都正常如果它们正常那就把注意力放到认证变量和 Base URL 上。1.1 doctor 的三类输出依赖、沙箱、认证依赖类通常长这样✓ Ripgrep、✓ Node、✓ npm。沙箱类会检查bubblewrap能不能在 Linux 上做进程隔离。认证类就是本文的重点原始报错是✗ Auth: not authenticated它的意思不是“没有 Key 文件”而是 Codex CLI 拿当前的 Key 和 Base URL 去请求模型通道时通道没有认出来。如果你的 terminal 里曾经export OPENAI_API_KEY...但 systemd 服务里没写那么手动跑codex doctor可能正常服务一启动就失败。反过来systemd 里写了变量但~/.codex/config.toml里没有把base_url指到统一通道它仍可能去请求默认地址。认证是一组信息Key、Base URL、模型 ID、环境变量名四个里错一个都会回到not authenticated或 401。1.2 systemd 里只写 OPENAI_API_KEY 为什么会缺认证systemd 服务默认不继承你 shell 里的export它只看 unit 文件里的Environment、EnvironmentFile或者系统级环境。原文示例要求写入OPENAI_API_KEY这本身没错但 Codex CLI 如果同时需要知道“去哪里认证”你就得把 Base URL 也交给它。比较稳的做法是在~/.codex/config.toml里声明一个自定义 provider把base_url固定成https://taotoken.net/api把env_key指向 systemd 里已经写好的变量名。这样 systemd 只负责把 Key 传进来endpoint 由配置文件决定少一个变量就少一个排障点。注意这个base_url不是官网落地页不要写成https://taotoken.net也不要画蛇添足加/v1。2. 去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿 Key 和模型 ID认证要过先得有可用的 Key。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并登录然后在控制台里创建 API Key。这个 Key 不要直接写进 Git 仓库也不要贴在 issue 里本地测试可以临时 exportsystemd 生产服务建议用EnvironmentFile指向一个权限为 600 的文件。创建完之后Key 的占位符统一写成YOUR_API_KEY后面所有示例都按这个来。2.1 创建 API Key 的占位符写法在控制台 API Keys 页面创建 Key 后复制出来的一长串就是真正要填进环境变量的值。示例里我用YOUR_API_KEY你替换成自己的即可。如果只是本机临时验证可以这样export OPENAI_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api这两行只对当前 shell 有效。关掉终端、切到 systemd变量就没了。所以后面还会写 systemd 的写法。别把OPENAI_BASE_URL写成带/v1的地址Codex CLI 对路径拼接比较敏感多一段就可能 404。2.2 模型广场里选 Codex 能用的模型 ID模型 ID 不要凭记忆写。不同通道、不同时间上架的模型名称可能变化正确来源是模型广场。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 之后进入模型广场找到准备给 Codex CLI 用的模型把 ID 原样复制。下面配置里的YOUR_MODEL_ID就替换成它。如果你不确定某个模型是否支持 Codex 的命令行调用方式先用模型对话页面发一条短消息验证 Key 和模型 ID。模型对话能用再回终端改config.toml这样排障范围会小很多。不要自己编造gpt-5、日期后缀或者不存在的名称写错模型 ID 时常见报错是 model not found而不是not authenticated但两者混在一起也会让人误判。3. 改 ~/.codex/config.toml把 Base URL 指到 https://taotoken.net/apiCodex CLI 的配置文件通常放在~/.codex/config.toml。如果没有这个文件可以手动创建目录和文件mkdir -p ~/.codex touch ~/.codex/config.toml接下来把模型、provider、Base URL、环境变量名写进去。核心目标是让 Codex CLI 在认证时走统一通道而不是走它默认记住的地址。3.1 最小可用 config.toml下面这段可以直接改成自己的值# ~/.codex/config.toml model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key OPENAI_API_KEY这里有几个点容易错。第一base_url是https://taotoken.net/api末尾没有/v1。第二env_key写的是环境变量名不是 Key 本身你 systemd 里写OPENAI_API_KEYYOUR_API_KEY这里就写OPENAI_API_KEY。第三model_provider和下面[model_providers.taotoken]的taotoken要对应别一个叫taotoken另一个叫openai。如果你的 Codex 版本要求显式声明wire_api以模型广场或接入文档里标注的协议为准没有要求就不要乱加。配置改完后先在当前 shell 里手动 export 同一把 Key再跑codex doctor确认配置层没问题再动 systemd。3.2 环境变量和 systemd 单元的正确写法systemd 服务不要只写一行EnvironmentOPENAI_API_KEYYOUR_API_KEY就结束。虽然 Key 传进去了但 Codex CLI 还需要知道 Base URL。可以在 unit 里补上[Unit] DescriptionCodex CLI worker Afternetwork-online.target [Service] Typesimple WorkingDirectory/home/youruser/codex-work EnvironmentOPENAI_API_KEYYOUR_API_KEY EnvironmentOPENAI_BASE_URLhttps://taotoken.net/api ExecStart/usr/local/bin/codex exec --full-auto 读取当前目录代码并输出修改建议不要执行生产库操作 Restarton-failure [Install] WantedBymulti-user.target如果你用EnvironmentFile文件内容可以写成OPENAI_API_KEYYOUR_API_KEY OPENAI_BASE_URLhttps://taotoken.net/api然后把文件权限改成 600并在 unit 里写EnvironmentFile/etc/codex-worker.env。这样 systemd 启动时会把变量注入进程codex doctor在服务上下文里也能读到。注意ExecStart不要写成让 Codex 直接连生产数据库执行 SQL它应该只生成、解释、对照代码或 SQL真正的诊断 SQL、编译、运行由你在本地或 SQL*Plus 里执行再把结果贴回对话。3.3 为什么不要写 /v1也不要填官网地址base_url填错是 404 的高发原因。统一通道的 Base URL 已经包含到 API 根路径写https://taotoken.net/api就够。有人习惯性补成https://taotoken.net/api/v1Codex CLI 再拼一次路径就会变成/api/v1/v1/...直接 404。另一种错法是填成https://taotoken.net那是给人看的官网地址不是给工具请求接口的地址。官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end用在注册、创建 Key、看模型广场、看用量这些动作上填进config.toml、systemd、CLI 的 Base URL 一律是https://taotoken.net/api。这两个不要混。4. Linux 依赖和沙箱仍按原文装npm、bubblewrap、ripgrep认证改到统一通道不代表安装步骤也要重来。Codex CLI 的 npm 全局安装、bubblewrap 沙箱、ripgrep 依赖仍按原文的 Linux 流程执行。TaoToken 只负责模型通道接入信息不负责替你装系统包。4.1 npm 全局安装与 Node 版本如果你的 Node 是系统仓库里的老版本先按原文确认 Node 版本满足 Codex CLI 要求。然后全局安装npm install -g openai/codex如果之前装过旧版本可以先看版本codex --version需要升级时再执行npm update -g openai/codex。安装完别急着跑服务先手动执行codex doctor看依赖块有没有红叉。若提示npm权限问题按原文建议配置 npm 全局目录或使用合适的 Node 版本管理方式不要直接sudo chmod -R 777。4.2 bubblewrap 和 ripgrep 的检查Debian/Ubuntu 系可以这样检查which bwrap which rg缺 bubblewrap 时通常安装sudo apt update sudo apt install -y bubblewrap ripgrepFedora/RHEL 系换成对应的包管理器命令。装完再跑一次codex doctor确认沙箱和搜索依赖变成通过。认证问题只改 Key、Base URL、模型 ID不要因为Auth红叉就去卸载 bubblewrap 或关掉沙箱。5. 验证codex doctor 通过后再让 Codex 生成一段只读命令配置写完后先手动验证再交给 systemd。手动阶段最怕的是 shell 里残留了旧变量所以建议开一个新终端只 export 一次然后依次跑 doctor 和一次短对话。5.1 doctor 通过长什么样export OPENAI_API_KEYYOUR_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api codex doctor如果配置正确认证那一行不再是✗ Auth: not authenticated。它可能显示为✓ Auth或者用文字说明认证已经通过。此时如果沙箱或 ripgrep 还有红叉按第 4 节处理。认证过了之后再去 systemd 上下文确认sudo systemctl daemon-reload sudo systemctl restart codex-worker sudo systemctl status codex-worker状态里不要有Failed to start。如果服务启动失败先看journalctl -u codex-worker -n 80 --no-pager重点看是不是OPENAI_API_KEY没读到或者OPENAI_BASE_URL被拼错。5.2 用 codex exec 做不碰生产库的验证服务起来后用一条只读任务验证通道codex exec 阅读当前目录的 README.md用三句话说明项目用途不要修改任何文件这条命令让 Codex 只做生成和解释不碰生产库、不执行诊断 SQL。如果它能返回合理内容说明 Key、Base URL、模型 ID 三者已经对上了。接下来你可以在对话里让它生成 SQL 或补丁建议但执行动作仍由你在本地、测试库或 SQL*Plus 里完成再把报错贴回对话继续分析。6. 401、404、模型不存在排障对照表排障时不要一次改五个地方。一次只改一个变量然后重跑codex doctor或codex exec才能知道是哪一处生效。6.1 401 与 Key 没被 systemd 读到现象常见原因处理401 UnauthorizedKey 写错、过期、systemd 没读到检查EnvironmentFile路径和权限确认变量名与env_key一致not authenticatedBase URL 仍是默认地址或 provider 没对应检查model_provider与[model_providers.taotoken]名称服务手动跑正常systemd 失败shell 里有 exportunit 里没有把 Key 写进EnvironmentFile重启服务systemd 的Environment不会自动读取~/.bashrc也不继承你登录 shell 的临时 export。用systemctl show codex-worker -p Environment可以看到实际注入的环境确认OPENAI_API_KEY和OPENAI_BASE_URL都在。6.2 404 与 base_url 多写 /v1如果报 404 或路径相关错误第一件事是看config.tomlbase_url https://taotoken.net/api确认末尾没有/v1也没有写成官网地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end。官网链接只用于注册和创建 Key不能加到base_url、curl、CLI 的-u或ANTHROPIC_BASE_URL这类工具变量上。改完配置后记得重启 systemd 服务。6.3 模型 ID 不对和 wire_api 不匹配模型 ID 报错通常不是not authenticated而是 model not found 或类似提示。回到模型广场从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 复制当前可用 ID替换config.toml里的YOUR_MODEL_ID。如果 Codex CLI 提示协议不匹配检查你的版本是否需要wire_api并以接入文档标注为准不要自己猜一个参数值。7. 排障完去控制台对一下这次调用codex doctor通过后别急着把 systemd 放到多台生产机上。先用同一把 Key 在模型对话页面发一条消息确认模型 ID 和通道都还能用再回控制台看这次调用有没有记上用量。Key 需要重建、禁用或换权限时也在控制台处理。这样你能把“认证通过”和“实际调用成功”分开验证不会等服务上线后才发现模型 ID 只在某次测试里能用。手动验证和 systemd 验证都通过后再考虑长期跑的套餐和 Key 管理。短测可以在 TaoToken 模型对话 里用同一把 Key 发测试消息长期让 Codex CLI 在 Linux 上做自动化任务可以打开 Coding Plan 看额度是否够用如果 Key 要重新创建或增加去 控制台 API Keys 操作。最后再回到~/.codex/config.toml核对base_url仍然是https://taotoken.net/api没有/v1也没有误填官网地址。
