跳转到内容

auto mode cannot determine the safety:Claude Code 报错

Quick fix

先升级 CC Switch;若仍报错,再按上游能力检查思考参数、模型映射、stop 支持及省略 stream 时的响应格式。

报错原文
Error: claude-opus-4-7[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash right now.

这条提示是 Claude Code Auto Mode 安全分类器失败后的通用错误,并不等同于模型下线。已报告的原因包括:CC Switch 3.14.1 的 `openai_chat` 转换未将 `thinking.type=disabled` 映射为上游实际支持的关闭思考参数,导致 reasoning 耗尽分类器的 token 预算;Copilot OpenAI Chat API 可能不支持 `stop`;旧切换流程还可能把默认模型 ID 而非用户配置的实际模型写入 `settings.json`。相关转换问题被维护者确认在 v3.15.0 修复或由 v3.16.0 覆盖,4.0 又重写了 Claude Code 切换流程。

但后续报告表明相同提示也可能来自上游限制:CC Switch 3.20.2 下有第三方 DeepSeek 上游无法真正关闭推理;4.0.11 的原生 Anthropic 透传案例中,维护者确认 CC Switch 已将省略 `stream` 视为非流式,而上游仍返回 SSE。因此升级后仍复现时,不能把所有变体归为同一个 CC Switch 缺陷,需要绕过 CC Switch 直连上游,对照检查响应与参数支持。

  1. 如果使用 CC Switch 3.14.1,先升级到 v3.15.0 或更高版本;维护者确认该版本修复了已知的 Auto Mode 路由/转换问题。

  2. 确认供应商的本地代理处于接管状态,并检查 Sonnet、Opus、Haiku 的实际请求模型。cc-switch 从 v3.9.0 起会按 `sonnet`、`opus`、`haiku` 等关键字映射分类器模型,第三方后端不需要直接支持 `claude-sonnet-4-6`。

  3. 若在 3.15.0 的 GitHub Copilot 配置中发现 `settings.json` 写入了默认模型 ID,可在 Claude 的 Common Config 中用供应商实际支持的模型覆盖相关变量;4.0 已重写切换流程并移除此合并机制,应在最新版检查切换后的值。

    settings.json
    {
    "env": {
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-opus-4.6",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-opus-4.6",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4.6",
    "ANTHROPIC_MODEL": "claude-opus-4.6",
    "ANTHROPIC_REASONING_MODEL": "claude-opus-4.6"
    }
    }
  4. 如果使用 `api_format=openai_chat`,直接测试上游是否支持关闭思考的参数以及 `stop`。部分上游即使收到 `enable_thinking:false` 仍会产生推理 token,此时需要由上游提供兼容能力,不能仅靠该参数修复。

  5. 如果使用 Local Routing 和原生 `anthropic` 格式,绕过 CC Switch 向供应商发送省略 `stream` 的同形请求并检查 `Content-Type`;若直接上游返回 `text/event-stream`,应向供应商报告,因为省略 `stream` 应返回非流式 JSON。

ToolClaude Code
Version未知
PlatformsWindowsmacOS
这个问题解决了吗?
部分原因已经修复:维护者确认已知的 Auto Mode 路由/转换问题在 v3.15.0 修复或被 v3.16.0 覆盖,4.0 也重写了模型配置切换流程。但同一通用错误仍可能由第三方上游无法关闭推理、不支持 `stop`,或在省略 `stream` 时错误返回 SSE 引起。
该转换路径是否已有推荐配置,或之前修复是否覆盖当前版本?
已知的 `openai_chat` 关闭思考转换曾被标记为已修复,但 3.20.2 的报告显示某些第三方 DeepSeek 上游即使收到关闭思考参数仍继续产生推理 token,因此是否覆盖取决于具体供应商能力。
如果主要应由上游解决,该如何确认?
绕过 CC Switch,用相同请求直接调用供应商端点,对比关闭思考参数是否生效、`stop` 是否被接受,以及省略 `stream` 时是否返回 JSON。若直连仍出现相同行为,应向上游供应商报告。

这是一个非官方社区 wiki,与 cc-switch 作者及项目本身无隶属关系。内容整理自项目公开的 GitHub issues。本站不分发任何软件。