谁会收到通知
工作区所有者和发起该操作的人会收到邮件。已连接 Telegram 时也会通过 Telegram 通知。同一请求会出现在控制台的审批页面。API 调用会看到什么
流式和非流式调用都会在第一轮审批时停止。 非流式响应包含status、run_id 和 thread_id。status 为 completed 或 awaiting_approval。仅在运行等待审批时才包含 pending_tool_approvals。仅当策略拒绝了某次调用时才包含 denied_tool_calls，其 reason 为 policy_deny。响应文本包含 [Waiting for approval: …]。
流式调用会先发送 tool_approval 事件，然后在最终 usage 事件上带上相同字段。
review_url 在登录后打开 https://app.fetchhive.com/{workspace_id}/approvals?approval={approval_id}。邮件令牌不会出现在 API 响应中。看起来像密钥的参数值会替换为 [redacted]。
如果响应同时包含 pending_delegations，请先处理工具审批。
关闭工具审批时，status 为 completed，并且不会返回审批数组。
如何答复
打开控制台链接、使用邮件链接，或用 API 密钥决定：POST /v1/public/workspaces/{workspace_id}/tool_action_approvals/{id}/decide
decision 为 allow_once 或 deny。always_allow 返回 422 always_allow_requires_dashboard。再次决定返回 409。已过期的审批返回 410。
如何继续
API 密钥调用会在决定之后由服务器自动继续。请轮询该运行或使用 webhook。不要再次调用该线程。 再次调用只用于第一方流式客户端。使用相同的智能体和thread_id，并带上 decided_tool_approvals: [{ "approval_id": "…" }]。message 可以是空字符串或一条新消息。只会读取 approval_id。
Webhook 触发或带有 async.callback_url 的调用会在决定之后自行继续。回调会先收到 agent.awaiting_approval，然后收到带有 resumed_from_run_id 的 agent.completed。
过期与轮次上限
审批在创建 24 小时后过期，除非设置了TOOL_APPROVAL_TTL_HOURS。一次运行链在五轮审批后停止，并附加 [Approval limit reached]。
始终允许
始终允许在控制台中设置。API 密钥不能创建该策略。为受信任的服务器跳过批准
工作区所有者或管理员可以允许一把 API 密钥自动批准操作。在“设置 → API 密钥”中勾选“允许此密钥自动批准操作”。成员不能更改该复选框。 使用该密钥的请求可以在POST /v1/agent/invoke 上发送 tool_approval: "auto_approve"。它只作用于这一次调用。它不会更改代理已保存的设置，也不会写入策略。省略该字段或发送 policy 时，遵循工作区规则，以及已经保存在代理、计划或部署上的自动批准开关。
破坏性操作仍然会询问。拒绝规则仍然会阻止操作。其他值会在运行开始前返回 400 invalid_tool_approval。
没有该权限的密钥、已登录编辑器的令牌，或 webhook，会在任何模型调用之前返回 403 tool_approval_override_not_permitted。当工作区关闭了自动批准时，返回相同的代码，消息为 “Auto-approve is not available for this workspace.”
这次运行中调用的子代理会收到相同的 tool_approval 值和同一把 API 密钥。代理启动的工作流不会继承它。工作流遵循自己部署上的开关。
响应会回显 tool_approval，值为 auto_approve 或 policy。如果某个操作因为例外而执行，响应还会包含 auto_approved_tool_calls，每一项都有 summary 和 tool_name。流式调用把这两个字段放在最终的 usage 事件上。