Agent 在用户连续拒绝权限审批后陷入无限思考循环

[NALAKUVARA313]

问题简述

在使用 DeepSeek Harness Web UI 时，Agent 在用户多次拒绝其权限审批请求后，陷入了“思考 → 申请审批 → 被拒绝 → 再思考”的无限循环，无法正常终止或接受用户的新指令。

复现步骤

在 Web UI 中启动一个 DeepSeek Harness 会话（默认 workspace-write + ask 权限模式）。

向 Agent 提出一个需要权限审批的任务（例如需要写入文件或执行命令）。

Agent 思考后发起一个权限审批请求（ctx.approval.request）。

用户在 UI 中点击 拒绝（Reject）。

用户开始在输入框中打字，准备向 Agent 说明拒绝原因和调整方向。

在用户尚未发送新消息的情况下，Agent 自动重新开始思考，分析“用户为什么拒绝”，然后自行提出一个“调整后的方案”，并再次发起新的审批请求。

用户再次点击拒绝，Agent 又再次自动进入思考循环。

即使 Agent 在思考中输出类似“你可能有别的想法，你说，我听”的语句，表示愿意倾听用户输入，但实际上它并未等待用户发送消息，而是继续自行思考并发起新一轮审批。

此循环持续不断，用户无法打断，也无法发送新的指令来纠正 Agent 的行为。

预期行为

当用户拒绝审批后，Agent 应停止当前动作，等待用户的下一条输入，而非自动重新思考并再次申请审批。

用户应能够在拒绝后立即发送新的指令，Agent 应优先响应用户的新输入，而不是继续自行循环。

或者在连续多次拒绝后，Agent 应主动暂停并请求用户明确指示，而不是无限重试。

实际行为

Agent 将用户的每次拒绝都视为一个需要“解决”的“任务结果”，触发新一轮的 Agent Loop，而不是将拒绝理解为“暂停并等待用户指令”。即使 Agent 在输出中表示愿意倾听，其底层循环机制仍未真正等待用户输入，导致用户无法介入对话。

环境信息

版本：v0.1 开发者预览版（当前 master）

运行方式：Web UI（默认 workspace-write + ask 权限模式）

权限策略：ask（默认）

补充说明

这个问题在交互式使用场景中严重影响用户体验。当 Agent 的理解出现偏差时，用户希望通过拒绝审批 + 文字说明来纠正 Agent，但当前的循环机制使得用户无法完成这个“纠正”动作，因为 Agent 不会等待用户输入就自行进入了下一轮循环。

官方文档中提到，ctx.approval 的 rejected 结果会导致工具体被跳过，调用方对 rejected 执行拒绝。但目前的实现中，rejected 似乎被 Agent 视为一个需要“重新尝试”的触发条件，而不是“停止并等待”的信号。

感谢开发团队的辛勤工作，这个预览版整体体验很棒，希望这个反馈能帮助改进产品！

[zoahdev]

Confirmed in code — this is a real loop bug, not model stubbornness.

Root cause

ToolRuntime.serviceAsk maps an approval rejected to an ordinary tool deny:

// packages/core/tools/src/index.ts
case 'rejected': return {
  decision: { kind: 'deny', reason: `the user rejected tool "${exec.name}"` },
  approvalCancelled: false,
}

prepareExecution then materializes that deny as a normal failed tool call:

content: [{ type: 'text', text: `Error: ${denialReason}` }], isError: true

So the model receives exactly Error: the user rejected tool "bash" — an error string, identical in shape to "file not found" or "command failed". A coding agent's trained response to an error is to re-plan and try again, which is why it re-thinks and re-requests approval. Nothing in that message tells the model "the user has taken over the conversation; stop and wait".

The escalation hint compounds it: a sandbox denial returns [sandbox: escalation available — retry this exact command once with sandbox_permissions...], so the model is explicitly invited to retry, and each retry asks approval again → reject → retry.

(The regression test at packages/core/tools/tests/tools.spec.ts even pins the current shape: text: 'Error: the user rejected tool "echo"'.)

Fix direction (two complementary layers)

1. Message-level: a rejected approval should produce a distinct, high-priority stop instruction (e.g. "The user rejected this action. Stop and ask the user what they would like instead — do not retry the same action."), not a generic error. Cheap, model-facing, immediately reduces the loop.
2. Loop-level: after a user rejection (not a sandbox denial), the agent loop should yield the turn instead of auto-kicking the next step, because rejection is a conversation turn, not a tool failure. This is the durable fix but touches the loop's continuation path, so it needs care.

I can prepare a cherry-pick-ready patch for (1) now (one branch, tool layer only, with a regression test). (2) is a loop-semantics change I'd scope against the maintainers' preferred behavior before touching — happy to draft a spec for it if useful.

[zoahdev]

Shipped layer (1) as promised — cherry-pick-ready against 47f943859b:

• Branch: zoahdev/deepseek-harness@fix/approval-reject-stop-instruction
• packages/core/tools/src/index.ts: rejected now returns The user rejected tool "X". Stop and ask the user what they would like to do instead — do not retry the same action or try to work around the rejection.
• Test updated; packages/core/tools/tests/tools.spec.ts → 136/136 green.

That is the model-facing half. The durable half is the loop-level yield-on-rejection (end the turn instead of auto-kicking the next step) — I left that out of this branch because it changes the loop's continuation semantics and I'd rather align on the maintainers' preferred behavior first. Happy to draft that as a spec/RFC if it helps.

[zoahdev]

Shipped the loop-level half now too — the complete fix is one branch.

• Branch: zoahdev/deepseek-harness@fix/approval-reject-conclude-turn (cherry-pick-ready against 47f943859b).
• The deny decision for a user rejection carries concludesTurn, error results can now forward that marker, and the agent loop commits the result and yields the turn instead of auto-continuing. The stop-and-ask message from the earlier branch is folded in.
• Key distinction preserved: a sandbox denial still does not conclude the turn (escalation stays available); only a user rejection yields, because rejection is a conversation turn, not a tool failure.
• core/tools tools.spec 136/136 with concludesTurn: true on the rejection result; pnpm typecheck clean.

This supersedes the message-only branch (fix/approval-reject-stop-instruction). If maintainers prefer the loop-level yield to be opt-in per deployment rather than unconditional, the concludesTurn marker is the single flag to gate.

[NALAKUVARA313]

Thanks for the quick fix! Looking forward to the merge. Great work!