Claude Code 的审批弹窗卡住或 AutoMode 返回限流错误时，直接重启会丢失现场。本文先建立可重复的交互和日志证据，再分别排查权限、视图状态、请求频率与回滚边界，避免把交互问题误判为模型故障。文中只讨论可在本地复现的步骤，不把单次结果扩展成产品承诺；每个结论都标注前提、证据和无法覆盖的边界。读者可以先完成最小验证，再根据自己的版本、权限和数据补充实验，避免把配置示例误当成普遍结论。
Claude Code 出现问题时，表面现象经常只有一句 Waiting：代码没有继续执行，终端也没有明显报错。真正的故障可能发生在权限审批、终端视图、分类器请求和 API 网关任意一层。排查重点不是反复重启，而是还原事件顺序，确认每个请求是否被发出、是否收到响应，以及响应有没有被正确交给下一个状态机。
1. 先区分“模型没响应”和“交互层没交付”
一个正在执行工具的 Agent，至少要经过下面几层：
如果模型请求没有发出，应该查 API、网络和模型路由；如果请求已经发出但弹窗没有出现，重点就变成客户端交互层；如果用户已经点击批准但 Agent 仍然等待，则要继续检查审批结果是否回传到原会话。
这一区分很重要。把所有 Waiting 都归咎于模型，会让团队不断更换模型，却忽略了真正的 UI 竞态或会话状态问题。
2. 审批弹窗卡住的稳定复现方法
社区公开案例中，较新的 Claude Code 版本出现过 Bash 权限审批偶发卡住。一个有价值的复现条件是：主对话即将发起审批时，按 Ctrl + O 进入 transcript 视图；此时终端可能停留在等待状态，审批控件没有按预期呈现。反向操作也可能触发中断：在审批即将出现的瞬间切换视图，当前对话被打断。
不要只记录“偶尔卡住”。建议把复现条件写成可执行步骤，并记录版本、终端类型和时间戳：
如果只能在“审批临界点 + 视图切换”组合下复现，就已经说明问题更接近交互事件竞态，而不是随机的模型质量波动。
3. 为什么会发生视图与审批竞态
终端 Agent 通常需要同时处理两类状态：一类是 transcript、主对话等视图状态，另一类是审批、输入、确认等请求/响应状态。早期实现可能使用 React state queue 排队弹窗；后续版本则可能统一到 dialog channel，通过请求创建、等待响应、恢复调用的方式处理交互。
当视图切换和审批请求共用一个生命周期，却没有明确的所有权和取消语义，就会出现竞态：
这个模型能解释两个看似相反的现象：弹窗不出现，以及切换视图后对话直接中断。它们可能共享同一个根因，即请求与界面生命周期之间缺少稳定关联。
排查时应收集哪些信息
建议在不记录密钥和业务正文的前提下，收集以下字段：
| 类别 | 记录内容 |
|---|---|
| 客户端 | Claude Code 版本、Node 版本、终端类型、操作系统 |
| 事件 | 工具调用开始、审批创建、视图切换、响应返回的时间戳 |
| 会话 | session ID、dialog/request ID、当前视图 |
| 结果 | 弹窗显示、用户动作、工具退出码、最终状态 |
| API | endpoint、模型、HTTP 状态、request ID、重试次数 |
其中 dialog/request ID 是关键。没有它，就很难证明“用户批准的响应”是否回到了正确的审批请求。
4. 安全的修复顺序：先隔离变量，再升级版本
遇到审批卡死，不要直接安装来源不明的二进制修复包。更稳妥的顺序是：
- 在测试项目中固定版本，确认问题能否稳定复现。
- 暂时关闭 transcript 切换等非必要交互，验证主流程是否恢复。
- 对比相邻版本，记录变更前后的触发比例。
- 查看官方 changelog、issue 和补丁源码，确认修复内容只涉及目标模块。
- 在隔离环境执行补丁，保留版本回滚和配置备份。
- 通过回归脚本覆盖“工具调用、审批、拒绝、视图切换、取消”五种路径。
临时规避只能用于定位问题，不能当成生产修复。例如，要求所有成员永远不切换 transcript，可能掩盖竞态，但无法解决多个 Agent 并发或远程终端下的生命周期问题。
5. AutoMode 分类器的高级配置
AutoMode 往往会先调用一个分类器，判断当前任务适合哪种执行策略或模型。分类器与主 Agent 可以使用不同模型，因此“主模型可用”并不代表 AutoMode 一定可用。
常见现象包括：分类器请求返回 429、分类结果超时、主流程降级到默认模式，或者因为分类器失败导致整个任务看起来没有响应。
如果客户端支持通过环境变量指定分类器模型，可以在测试环境显式设置：
这里的重点是配置隔离，而不是追求某个固定模型名称。企业环境应把分类器模型放进版本化配置，并为开发、预发布、生产分别设置允许的模型白名单。切换后需要验证：
不要通过无限重试掩盖 429。分类器是高频小请求，连续重试反而会放大限流。更合理的做法是指数退避、设置最大重试次数，并在超过阈值后使用已批准的默认路由。
在审批和 AutoMode 场景中，网关至少要提供以下治理能力：
- Key 分组：按团队、项目、开发/生产环境拆分凭证，避免一个 Key 失控影响全部工作流。
- 模型路由：将主 Agent、分类器和备用模型分别配置，避免分类器意外占用高成本主模型额度。
- 日志追踪：关联
workflow_id、session_id、request_id、model、endpoint和http_status，定位“请求未发出、请求失败、响应未解析”三类问题。 - 限流与预算：对分类器设置独立配额，按项目设置日预算和并发上限，429 时触发告警而不是无限重试。
- 降级策略：仅切换到同样经过权限和质量验证的备用模型，并在日志中标注降级原因。
示例日志可以保持结构化，同时脱敏输入内容：
7. Ctrl+C、扩展模式与版本兼容性
高级功能通常会改变终端快捷键、会话中断和工具权限的默认行为。升级后需要单独验证 Ctrl+C 的语义：它可能是取消当前工具、停止 Agent，或在特定模式下触发退出确认。团队不应凭经验假设快捷键行为永远不变。
对于名为 ultracode、增强模式或类似扩展能力的功能，排错边界也要保持清晰：
- 只使用官方文档或已审查源码中明确支持的配置；
- 不通过修改客户端校验、伪造授权信息来解锁功能；
- 扩展功能使用独立的测试 Key 和项目权限；
- 升级前后分别执行工具调用、审批和取消回归测试；
- 出现异常时优先回滚版本或关闭扩展，而不是继续叠加补丁。
8. 生产上线检查清单
9. 总结
Claude Code 的高级故障往往不是单一模型错误，而是交互状态、工具权限、分类器请求和 API 网关共同作用的结果。遇到审批弹窗卡住，应先建立稳定复现条件，再用事件时间线确认 dialog 请求是否跨越视图生命周期；遇到 AutoMode 429，应把分类器当成独立流量治理，而不是无限重试。
参考来源
结论
本文给出了问题定位、配置或验证的可执行路径。实际结果仍取决于当前版本、权限和运行环境，提交前应按官方文档复核可变字段，并保留失败证据和回滚边界。
