Claude Code 报错 temporarily unavailable, so auto mode cannot determine the safety of bash 怎么解决
现象
在 Claude Code 的 auto 模式（自动批准权限模式）下干活，某次工具调用突然被拦，终端里出现类似这样的提示：
error: claude-opus-5[1m] is temporarily unavailable, so auto mode cannot determine the safety of bash right now. wait a moment and then try this action again. if it keeps failing, continue with other tasks that don't require this action and come back to it later. note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.
模型名可能是 claude-opus-4-8、claude-sonnet-4-6、claude-sonnet-5、claude-fable-5，也可能是 glm-5.3、k3 这类第三方模型；bash 的位置可能是 write、edit、webfetch、websearch、skill、croncreate 甚至某个 MCP 工具名；括号里的原因可能是 timed out、server error、rate-limited、connection failed，或者干脆没有括号。这些全是同一个问题，处理方式一样，下文有完整变体速查。
根因：挂掉的是"判定器"，不是你的命令被判危险
auto 模式的本质是把"人工点确认"换成"模型判定器"：每次要执行 Bash、写文件这类有副作用的动作前，Claude Code 会额外发起一次受限的模型调用，让会话模型扮演安全监视器（system prompt 开头就是 "You are a security monitor for autonomous AI coding agents"），只吐一个危险度判分。我们此前用本地日志代理把这次判定请求整包抓下来逐段解析过，机制细节可以看那篇。
看懂机制，这条报错就好理解了：
- 报错说的是判定器这次调用失败了——模型服务暂时不可用/超时/限流，判分拿不到。
- 拿不到判分时，Claude Code 的选择是"宁可不做"：既不放行也不判罪，让你稍后重试。所以这不是对你命令的安全判定（新版报错文案甚至直接写了 "This is not a judgement about the action"）。
- 只读操作（读文件、搜代码）不需要判分，所以照常能用——这也解释了为什么卡住的总是 bash/write/edit 这类动作。
解决：按顺序试这四步
- 等几秒，原样重试。绝大多数情况是模型服务的瞬时抖动（高峰期尤其常见），重试一两次就过了。
- 先干别的。让 Claude 继续做只读类工作（读代码、分析、规划），过几分钟再回头执行被卡的动作——报错文案自己推荐的就是这个策略。
- 持续失败：换个会话模型。判定器用的就是你的会话模型——
/model切到另一个可用模型，判定器会跟着换。如果claude-opus-5在过载，切claude-sonnet-5往往立刻恢复。用第三方路由（报错里出现glm-5.3、k3等名字的场景）同理：切回官方模型或换一个健康的后端。 - 还不行：退出 auto 模式。切回默认权限模式（每次动作人工确认），判定器就不在链路里了，动作照常执行——代价是你要自己点确认。确认完这波工作，再切回 auto。
另外有一个近亲报错：「error: auto mode could not evaluate this action and is blocking it for safety」——同样是判定环节没能给出结论时的保守拦截，处理方式与上面完全相同。
变体速查：你看到的是不是这一族
对照下面三个槽位，句式对上就是本文说的问题：
模型名槽位（谁在当判定器）：
claude-opus-5[1m] / claude-opus-4-8[1m] / claude-sonnet-4-6[1m] / claude-sonnet-5 / claude-fable-5[1m] / glm-5.3[1m] / k3[1m] / model-sonnet[1m] / 其他任何模型 ID。[1m] 后缀只是表示该模型开着 1M 上下文窗口，与本报错无关。
动作槽位（哪个工具被卡）：
the safety of bash / write / edit / webfetch / websearch / skill / agent / croncreate / mcp__<服务名>__<工具名>——任何有副作用的工具都可能出现在这里。
原因槽位：
(timed out) / (server error) / (rate-limited) / (connection failed) / 无括号——分别对应超时、5xx、限流、连接失败，处理方式无差别。
FAQ
是不是我的命令被认定危险了？
不是。危险命令有另一套提示（判定器正常工作时的拦截）。这条报错明确说的是判定器联不上，与命令内容无关——模型过载时，mkdir tmp 这种再无害的写操作一样会撞上它。
为什么用的是 GLM/Kimi，也报这个错？
通过 claude-code-router、one-api 这类路由把 Claude Code 接到第三方模型时，判定器调用也走你配置的后端。第三方后端不稳定时，这条报错里就会出现对应的模型名。处理方式一样：换健康的后端或官方模型。
只读操作为什么不受影响？
判定器只管有副作用的动作（执行命令、写文件、发请求）。读文件、搜索代码这类操作不改变任何状态，设计上就不需要判分，所以判定器挂了它们照常工作。
这个判定器到底怎么工作的？
一句话：会话模型的一次受限调用，11.6 万字符的系统提示词，两级规则（HARD BLOCK / SOFT BLOCK / ALLOW）加两阶段判定。完整抓包解析见《抓包拆开 Claude Code auto 模式的判定器》；想知道这套判定器的真实边界（以及它能被什么样的注入链绕过），见《复现一条能打穿 Claude Code auto 模式的注入链》。
教训
遇到 AI 工具链的报错，先分清"判定失败"和"被判定为坏"——前者是基础设施问题（等待/换路重试），后者才是内容问题（改方案）。这条报错的措辞其实已经把答案写在里面了，但在终端里刷出一大段红字时，多数人（包括我们）第一反应都是"我干了什么坏事"。
