为什么开启接管后，我的第三方 Provider (如 sglang) 会报 401 Unauthorized？

早期版本的代理转发器未将 PROXY_MANAGED 替换为真实 API Key 就直接发送给了 openai_chat 格式的后端。请升级至 v3.17.0+，或临时手动将真实 API Key 写入 ~/.claude/settings.json。

我使用的是 JS 版 Codex CLI，为什么接管后提示登录且模型配置不生效？

早期版本仅适配了 Rust 版 Codex 的配置格式（如 config.toml），JS 版无法识别 PROXY_MANAGED 占位符及 .toml 配置。建议通过设置环境变量 CODEX_RUST=1 统一使用 Rust 版，或等待后续版本适配。

Your access token could not be refreshed Codex

Quick fix

升级 cc-switch 至 v3.17.0+，修复接管时写入 PROXY_MANAGED 占位符污染 OAuth 凭证或导致 401 的问题。

Symptom

报错原文

Your access token could not be refreshed because your refresh token was already used. Please log out and sign in again.

Cause

早期版本的 cc-switch 在开启本地路由接管时，会向配置文件（如 Codex 的 auth.json 或 Claude Code 的 settings.json）写入 PROXY_MANAGED 作为占位符以标记接管状态。对于使用官方 OAuth 登录的 Codex，该占位符会污染或覆盖原有的登录凭证，导致 token 刷新失败；对于 Claude Code 的 Codex OAuth 场景，接管逻辑会错误删除 ANTHROPIC_AUTH_TOKEN，从而触发登录提示。此外，若占位符残留并被直接发送至官方接口或第三方 openai_chat 后端，则会引发 401 鉴权错误。官方已在 v3.17.0 中重构接管逻辑，不再写入占位符并保留真实凭证。

Fix

升级 cc-switch 至 v3.17.0 或更新版本。该版本重构了官方会话的接管路由，不再写入占位符，并会主动清理残留的 PROXY_MANAGED。
2
若暂时无法升级且遇到 Codex 官方登录失效，需手动清理 ~/.codex/auth.json 中的占位符并重新执行 OAuth 登录。
```
// ~/.codex/auth.json
{
  "OPENAI_API_KEY": "PROXY_MANAGED"
}
```
3
若遇到 Claude Code 提示登录，需手动在 ~/.claude/settings.json 的 env 中补回 ANTHROPIC_AUTH_TOKEN 字段。
```
// ~/.claude/settings.json
{
  "env": {
    "ANTHROPIC_API_KEY": "PROXY_MANAGED",
   "ANTHROPIC_AUTH_TOKEN": ""
  }
}
```

Affected Versions

ToolCodex

Version未知

PlatformsmacOSWindows

Source Issues

本页汇总自 5 个真实 issue

FAQ

为什么开启接管后，我的第三方 Provider (如 sglang) 会报 401 Unauthorized？: 早期版本的代理转发器未将 PROXY_MANAGED 替换为真实 API Key 就直接发送给了 openai_chat 格式的后端。请升级至 v3.17.0+，或临时手动将真实 API Key 写入 ~/.claude/settings.json。
我使用的是 JS 版 Codex CLI，为什么接管后提示登录且模型配置不生效？: 早期版本仅适配了 Rust 版 Codex 的配置格式（如 config.toml），JS 版无法识别 PROXY_MANAGED 占位符及 .toml 配置。建议通过设置环境变量 CODEX_RUST=1 统一使用 Rust 版，或等待后续版本适配。

Your access token could not be refreshed Codex

Symptom

Cause

Fix

Affected Versions

Source Issues

FAQ

相关问题