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」——同样是判定环节没能给出结论时的保守拦截，处理方式与上面完全相同。
权限模式速查：切到哪个模式就不会再撞这条报错
第 4 步说的"退出 auto 模式"具体怎么操作：会话里按 Shift+Tab 循环切换权限模式（二进制里那句提示原文就是 Shift+Tab to change mode），或者启动时用 --permission-mode <模式> 直接指定。本机 Claude Code v2.1.263 的 claude --help 列出六个取值：
--permission-mode 值 |
干什么的 | 常见中文叫法 |
|---|---|---|
plan |
只读只规划，不动手 | plan mode、计划模式 |
manual |
每个有副作用的动作都问你一次 | manual mode、手动确认 |
acceptEdits |
自动接受文件编辑 | accept edits on、自动接受编辑 |
dontAsk |
不再询问 | — |
auto |
本文报错的来源：用模型判定器替掉人工确认 | auto 模式、自动批准、自动同意所有命令、全自动模式 |
bypassPermissions |
官方原文 "Bypass all permission checks" | bypass permissions、跳过全部权限检查 |
会额外调用安全判定器的是 auto 模式。切到上表任意其它模式，判定器就不在链路里了，这条报错随之消失——代价见各模式本身的取舍：manual 要你逐个点确认；bypassPermissions（等价于命令行的 --dangerously-skip-permissions）官方只建议在没有外网的隔离环境里用，别拿它当日常提速手段。
如果想让 Claude Code 默认就进 auto 模式，把 "defaultMode": "auto" 写进用户级的 ~/.claude/settings.json，并确认项目级 / local 设置里没有另一个 defaultMode 盖住它——后者优先级更高，这是"明明配了却没生效"的常见原因。
变体速查：你看到的是不是这一族
对照下面三个槽位，句式对上就是本文说的问题：
模型名槽位（谁在当判定器）：
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) / (overloaded) / (connection failed) / 无括号。前五种分别对应超时（60 秒）、5xx、限流、529 过载、连接失败，Claude Code 已经自动重试过，等一会儿再试即可。无括号不一样：表示后端直接拒收了判定请求（4xx），只试 1 次，重试多少遍都没用，要去查后端配置。各原因的实测对照见《Claude Code 接 DeepSeek / GLM / Kimi 开 auto 模式：括号里的原因怎么看》。
FAQ
auto 是什么模型？
auto 不是模型，是权限模式。这个误会很常见，因为报错里紧挨着 auto 的就是一个模型名。实际关系是：你用 /model 选的那个会话模型（claude-opus-5、claude-sonnet-5，或者第三方的 glm-5.3、k3）在 auto 模式下要兼职当判定器，所以报错里出现的是你自己的会话模型名，不存在一个叫 auto 的模型。
「bash denied by auto mode」是同一个问题吗？
不是，正好相反，这两条别混：
- temporarily unavailable / could not evaluate：判定器联不上或没能给出结论，属于基础设施抖动。等一会儿重试、换会话模型、或切出 auto 模式即可。
- denied by auto mode：判定器正常工作，并且判定这条命令不安全。重试多少次都是同一个结果，得改命令写法、把它加进允许规则，或者切到手动确认模式自己放行。
分不清这两者，就会出现"一直重试一条永远不会被放行的命令"。
我的 Claude Code 里没有 auto 模式怎么办？
按 Shift+Tab 循环一圈看不到 auto，通常是版本太旧。最直接的判断方式是跑 claude --help，看 --permission-mode 的取值列表里有没有 auto（本机 v2.1.263 是有的）；claude --version 可以确认当前版本。升级后 auto 会重新出现在 Shift+Tab 的循环里。
是不是我的命令被认定危险了？
不是。危险命令有另一套提示（判定器正常工作时的拦截）。这条报错明确说的是判定器联不上，与命令内容无关——模型过载时，mkdir tmp 这种再无害的写操作一样会撞上它。
为什么用的是 GLM/Kimi，也报这个错？
通过 claude-code-router、one-api 这类路由把 Claude Code 接到第三方模型时，判定器调用也走你配置的后端。第三方后端不稳定时，这条报错里就会出现对应的模型名。处理方式一样：换健康的后端或官方模型。每个动作的判定请求约 3 万输入 token、超过 60 秒没回就报 timed out，第三方后端下各类失败的实测对照见这篇。
只读操作为什么不受影响？
判定器只管有副作用的动作（执行命令、写文件、发请求）。读文件、搜索代码这类操作不改变任何状态，设计上就不需要判分，所以判定器挂了它们照常工作。
这个判定器到底怎么工作的？
一句话：会话模型的一次受限调用，11.6 万字符的系统提示词，两级规则（HARD BLOCK / SOFT BLOCK / ALLOW）加两阶段判定。完整抓包解析见《抓包拆开 Claude Code auto 模式的判定器》；想知道这套判定器的真实边界（以及它能被什么样的注入链绕过），见《复现一条能打穿 Claude Code auto 模式的注入链》。
教训
遇到 AI 工具链的报错，先分清"判定失败"和"被判定为坏"——前者是基础设施问题（等待/换路重试），后者才是内容问题（改方案）。这条报错的措辞其实已经把答案写在里面了，但在终端里刷出一大段红字时，多数人（包括我们）第一反应都是"我干了什么坏事"。