AUTO mode: user approvals never reach the classifier (blocks are unoverridable); approval mode also reverts to AUTO on session rebuild

[chiga0]

What happened?

A production data change was being carried out through an API-driven host harness (not the interactive TUI). The agent asked the user to confirm the change with ask_user_question, the user answered affirmatively three separate times, and each time the subsequent tool call was still refused with reason: classifier_blocked. Zero statements were executed, and the user waited ~10 minutes across three confirmation round trips.

Two defects in AUTO mode compose into that outcome. Both were re-verified against current main (05b8ee06a261) by reading the code, so the mechanism is not fork-specific.

What did you expect to happen?

Two things, corresponding to the two defects below:

• When AUTO mode's classifier refuses an action because it wants explicit user confirmation, a confirmation the user actually gave through the product's own first-party confirmation tool should be able to satisfy that requirement — or at minimum the gate should not report "no confirmation was obtained" when one is in the transcript.
• When a caller sets a session's approval mode through the documented daemon API, that value should either survive a rebuild of the session's runtime, or the change away from it should be visible to the caller. A silent convergence on AUTO flips the permission model under a running integration without any signal.

Neither expectation is about making AUTO mode more permissive. Defect 1 asks the gate to be able to see evidence of authorization that is already committed; Defect 2 asks the runtime to stop changing an operator-owned invariant by itself.

---

Defect 1 (root cause): the classifier is asked to require a user confirmation it is structurally unable to see

buildClassifierContents projects the conversation into the transcript the LLM classifier reads (packages/core/src/permissions/classifier-transcript.ts:98-153, main@05b8ee06a261):

• role === 'user' → text parts retained
• role === 'model' → only functionCall parts, re-rendered as user-role text turns of the form `Prior action: ${toolName}(${JSON.stringify(projected)})` (:209-217)
• role === 'function' (tool results) → fully stripped, with a comment that says so explicitly (:143)

A tool result is the only representation a tool call's answer can have. So when the agent calls ask_user_question and the user answers, the classifier receives:

Prior action: ask_user_question({"questions":[…]})   ← it can see that the question was asked
## Pending tool call to classify
Tool: <the action that question was about>            ← and the action now under review

It never sees the answer. The ask_user_question tool itself is in SAFE_TOOL_ALLOWLIST (packages/core/src/permissions/autoMode.ts:62-86), so the question is never blocked — the confirmation is collected by the host UI, committed as an authoritative permission vote, and then discarded on its way to the only component that asks for it.

The three refusals in this incident each said, in effect, "this requires explicit user confirmation, which was not obtained" — with three different wordings, i.e. LLM-generated, not a deterministic rule. Given a projection that omits the confirmation by construction, a refusal is the only self-consistent output.

Why the user cannot release it

applyAutoModeDecision (autoMode.ts:544-580) has a genuinely asymmetric pair of branches:

verdict	what the user gets
classifier_unavailable	{kind:'fallback'} → falls through to the manual approval dialog, decorated with "Switching to Default Mode is recommended" (formatClassifierUnavailableFallbackMessage, autoMode.ts:629-635, decorateClassifierUnavailableConfirmation, :637-653)
classifier_blocked	{kind:'blocked'} → a tool error to the model (EXECUTION_DENIED, not_started), coreToolScheduler.ts:3072-3092

'blocked' creates no permission request, so there is nothing for the user to answer. The block is visible to the model and to autoModeDebugLogger only; from the operator's side the turn just says "blocked by safety policy" and repeats.

The escape hatch is disarmed by the guidance that ships with the block

shouldFallback (packages/core/src/permissions/denialTracking.ts:127-143) does provide a way out: once consecutiveBlock >= AUTO_MODE_DENIAL_LIMITS.maxConsecutiveBlock (= 3, :37-40), the next classifier-requiring call is passed as skipClassifierReason (coreToolScheduler.ts:3002, :3020-3022) and resolves to {via:'fallback'} → a real manual dialog.

Three properties make it unreachable in exactly the situation where it matters:

1. It is consulted on the next call, before the classifier runs, so it never releases the call that is blocked now. The user needs a fourth attempt at the same action.
2. Every block appends AUTO_MODE_DENIAL_GUIDANCE (autoMode.ts:627, attached at :558 and :664), which instructs the model to "stop and ask the user for explicit approval" and not to attempt the denied action again. An agent that follows this instruction — ours did, all three times — never produces the fourth attempt. Obedience to the denial guidance is what prevents the recovery path from arming.
3. Nothing else clears the streak in between. ask_user_question and other allowlisted tools return through the L5.2 fast path before evaluateAutoMode runs, so they call neither recordAllow nor recordBlock. Only a classifier-approved call clears it (autoMode.ts:552, denialTracking.ts:82-90) — but the agent has no other reason to be making classifier calls while it is waiting for the user.

So the loop closes: the gate demands a confirmation → the confirmation is stripped from the gate's input → the remedy the gate itself advertises ("ask the user") cannot satisfy it → the fallback that could release it requires retrying the action the guidance forbids retrying.

Note this is not a bypass hole in the intended direction: AUTO mode is supposed to be more conservative than the user, and #4538 hardened it against exactly that. The problem here is the opposite — the mode cannot accept a stronger authorization than the model's own estimate, even when a human has supplied one through the product's own first-party confirmation tool.

Reproduction

Defect 1 does not depend on the harness or on any fork change, and is reproducible deterministically at the projection level without an LLM:

1. Build a Content[] transcript containing a model message with a functionCall part for ask_user_question, followed by a function response part whose text is the user's affirmative answer, followed by a pending action.
2. Call buildClassifierContents(messages, toolRegistry, pendingAction).
3. Observe: the returned projection contains Prior action: ask_user_question({...}) and the pending action, and contains no trace of the answer — asserted by the role === 'function' branch at classifier-transcript.ts:143.

End-to-end in interactive AUTO mode requires a prompt the classifier reliably blocks, so it is nondeterministic; the projection test above is the tight form. Happy to contribute it.

Suggested direction

The answer to ask_user_question is not untrusted tool output — it is a user selection collected and committed by the host through the permission-vote path, i.e. the highest-trust input the session has. Options, roughly in increasing cost:

• Add a trusted-source allowlist to the projection so committed interactive answers (a bounded set: ask_user_question, plus explicit permission-vote results) survive as user-role text turns, while all other tool results stay stripped. This keeps the existing orphan-functionCall rationale intact for everything else.
• Alternatively/additionally, make a classifier block on an action that is preceded by a committed interactive confirmation arm the manual-approval dialog directly, instead of requiring a fourth attempt.
• At minimum, include a "the user has confirmed this via …" signal in the block payload so the block is auditable and the model is not told to gather evidence the gate will ignore.

---

Defect 2 (trigger): an approval mode set through the daemon session API is not durable across a session runtime rebuild

Same incident, the other half. AUTO was never chosen for this session. The harness set a non-AUTO mode once, at session creation, via the documented route; every turn after that ran in the mode it had set — until the session's runtime was reclaimed and rebuilt.

The mode lives on Config as runtime state (packages/core/src/config/config.ts:2265) and is re-derived at construction as params.approvalMode ?? ApprovalMode.AUTO (:2588). It is not carried in the persisted session record. The daemon applies a caller-supplied mode only when the request includes one (the resume path guards it with if (approvalMode), packages/acp-bridge/src/bridge.ts:5558; applyApprovalMode is at :5747), so a session/resume that merely reattaches rebuilds the runtime on the built-in default.

Observed, on a single unchanged daemon process, in the OTel trace: 6 turns run in the caller's mode → ~84 minutes idle → the next turn's trace contains qwen-code.daemon.session_restore (action=resume) followed by qwen-code.config reporting auto, and every subsequent turn in the session is auto. The caller's mode-setting request count for the whole session is 1. The idle gap is not unusual; DEFAULT_SESSION_IDLE_TIMEOUT_MS is 30 * 60_000 with a 60 s sweep (bridge.ts:2668-2669), i.e. shorter than a lunch break, and DEFAULT_SESSION_PROMPT_SETTLED_CLOSE_GRACE_MS is 0 (:2673) — the grace that exists so poll-based clients are not torn down between polls is off by default, so a poll-based client's session is a reaper candidate as soon as it has no SSE subscriber and no in-flight work (entryIsAutoCloseCandidate, :3119-3145).

This is the second silent AUTO-convergence path I found; the first is settings reload, and it is deliberate: foldReloadApprovalMode folds a missing or falsy tools.approvalMode to AUTO and pushes it to live sessions, with the comment "so a key deletion reaches live sessions on reload instead of pinning a stale privileged mode until daemon restart" (packages/cli/src/acp-integration/acpAgent.ts:1844-1871). I agree with that intent for an interactively-owned session. I don't think it extends to a mode a programmatic caller owns per-session through the API, whose value can now be revoked by an unrelated settings edit or a runtime rebuild.

What makes this hard to run safely:

• The rebuilt mode is already reported to the caller: session/load and session/resume responses include modes.currentModeId, built at acpAgent.ts:14411-14421 (attached at :5116, :5270, :5594, :5683). Nothing in the response says the value differs from the one the caller set, and there is no event for the transition.
• Config already tracks approvalModeRevision (config.ts:2267, :7061). A rebuilt runtime starting at revision 0 in a mode the caller never asked for is exactly what a comparison would catch — that signal is not surfaced to the API caller today.

Suggested direction

Any one of these would let a harness stop guessing:

1. Persist the last explicitly-set per-session mode with the session record and restore it on rebuild, or
2. Emit a currentModeId-vs-expected discrepancy in the load/resume response, or a session-update event when a rebuilt/reloaded runtime's mode differs from the last explicitly-set value (with the reason), or
3. Accept a expectedApprovalMode / compare-and-set parameter on session/resume so the caller can state its invariant and get an error rather than a silent downgrade.

We will implement the client-side workaround regardless — re-applying the mode after a cold restore, and cross-checking modes.currentModeId on every resume, since the value is already in the response at no extra round-trip cost — but the durable semantics belong here, and a client cannot distinguish "drifted on rebuild" from "a human deliberately changed it mid-session", which is why option 2 or 3 is worth more to us than option 1.

---

Client information / verification status — please read before triaging

• Observed in production on a downstream fork based on the 0.22.x line, in qwen serve / daemon mode driven by an API harness, on Linux containers. The deployment is not a stock upstream release, so I am not claiming a stock v0.23.0 reproduction, and I have not pasted /about from one.
• Auth is not implicated here — the model calls, the confirmation votes, and the tool executions all succeeded or failed on permission policy, not credentials.
• I re-verified both mechanisms against main@05b8ee06a261 by reading the cited files at that commit, and every line reference above resolves in it. The code paths involved (classifier-transcript.ts, autoMode.ts, denialTracking.ts, coreToolScheduler.ts's L5 gate, config.ts:2588, the bridge reaper defaults) are upstream-owned, not fork modifications, to the best of my diff review.
• Defect 1 is the reason the incident was unresolvable; Defect 2 is the reason it happened at all. Neither is sufficient alone: in the caller's original mode there is no classifier, and in AUTO with a persistent mode the harness would have noticed the drift on turn 7 rather than after three failed confirmations.
• Related but distinct, and not what this issue is about: Auto-mode permission classifier resilience: fail-open on unavailability (regression of #7331), deterministic allow-rule short-circuit, configurable timeout/fallback #9639 (classifier unavailability resilience), qwen serve: built-in shell guard ignores the session approval mode, denies read-only Git and non-Git commands outside the session directory, and cannot be configured, audited, or surfaced to the operator #10860 (shell guard ignoring the session mode), Track AUTO mode telemetry and classifier parity #4475 (AUTO telemetry/classifier parity), Harden AUTO mode against self-modification and denial bypass #4538 (hardening AUTO against bypass).

Edge already ruled out on our side

The confirmation votes were genuine and committed (HTTP 200 on the daemon permission route, three distinct request ids), and the denial was recorded against a session that had been idle long enough to be rebuilt. So this is not a lost-vote or transport bug, and not a case of ask_user_question being suppressed by the mode — that tool is on the allowlist and fired correctly every time.

I'd like to fix Defect 1 upstream if you agree with the trusted-source-projection framing; I'd start with the projection unit test above plus the allowlist carve-out, and keep everything else stripped.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: bug — two independently fixable defects reported in one thread (the core AUTO-mode classifier gate, and daemon session approval-mode durability)
• Labels: kept type/bug, category/security, daemon; added scope/core, scope/session-management, priority/P2, need-discussion; removed status/needs-triage
• Duplicates: none found. Related but distinct: Auto-mode permission classifier resilience: fail-open on unavailability (regression of #7331), deterministic allow-rule short-circuit, configurable timeout/fallback #9639 (classifier unavailability), AUTO mode: make MCP tool calls classifiable (forward bounded arguments, destructiveHint fallback, strip server-level allow rules) #10353 (MCP classifiability), Track AUTO mode telemetry and classifier parity #4475 (AUTO telemetry parity), Harden AUTO mode against self-modification and denial bypass #4538 (closed — hardening AUTO against bypass), qwen serve: built-in shell guard ignores the session approval mode, denies read-only Git and non-Git commands outside the session directory, and cannot be configured, audited, or surfaced to the operator #10860 (shell guard ignores the session mode)
• Next: static verification of both cited mechanisms against main@80497a74d0e8, then a scope and fix-direction recommendation

中文说明

• 类型: bug —— 同一个 issue 里包含两个可独立修复的缺陷（core AUTO 模式分类器门禁；daemon 会话审批模式的持久性）
• 标签: 保留 type/bug、category/security、daemon；新增 scope/core、scope/session-management、priority/P2、need-discussion；移除 status/needs-triage
• 重复: 未发现重复。相关但不同：Auto-mode permission classifier resilience: fail-open on unavailability (regression of #7331), deterministic allow-rule short-circuit, configurable timeout/fallback #9639（分类器不可用）、AUTO mode: make MCP tool calls classifiable (forward bounded arguments, destructiveHint fallback, strip server-level allow rules) #10353（MCP 可分类性）、Track AUTO mode telemetry and classifier parity #4475（AUTO 遥测对齐）、Harden AUTO mode against self-modification and denial bypass #4538（已关闭 —— 防止绕过 AUTO 的加固）、qwen serve: built-in shell guard ignores the session approval mode, denies read-only Git and non-Git commands outside the session directory, and cannot be configured, audited, or surfaced to the operator #10860（shell guard 忽略会话审批模式）
• 下一步: 基于 main@80497a74d0e8 静态核对两处被引用的机制，然后给出范围与修复方向的建议

Verification and analysis

Evidence carried here: static source reading only. This is an unattended CI triage, so nothing was built or executed — no reproduction, no live classifier call, no daemon run. Every line reference below was read at main@80497a74d0e8; line numbers have drifted a few lines from the reporter's 05b8ee06a261, and the values given here are the current ones.

Defect 1 — confirmed, all five links in the chain resolve

1. The answer is stripped by construction. buildClassifierContents (packages/core/src/permissions/classifier-transcript.ts:98) keeps user text, re-renders each model functionCall as a user-role turn Prior action: name({...}) (:215), and drops every role === 'function' part (:145). The strip is deliberate and documented at :12 — "Tool results are fully stripped — they may contain untrusted content". A tool result is the only representation an answer can have, so the classifier cannot see it.
2. The ask itself never touches denial state. ToolNames.ASK_USER_QUESTION is in SAFE_TOOL_ALLOWLIST (packages/core/src/permissions/autoMode.ts:76), and shouldRunAutoModeForCall early-returns false for it (:122, guard at :127). The scheduler's L5 branch is gated on that predicate, so a confirmation round trip calls neither recordAllow nor recordBlock. Nothing clears the streak in between.
3. Blocked and unavailable are genuinely asymmetric. In applyAutoModeDecision (autoMode.ts:544): classifier_unavailable → {kind:'fallback'} → a real manual dialog, decorated by decorateClassifierUnavailableConfirmation with "Switching to Default Mode is recommended"; classifier_blocked → {kind:'blocked'} → an EXECUTION_DENIED / not_started tool error to the model (coreToolScheduler.ts:3072). A block creates no permission request, so there is nothing for a user to answer.
4. The escape hatch arms a future call, not the blocked one. maxConsecutiveBlock: 3 (packages/core/src/permissions/denialTracking.ts:38); shouldFallback (:128) is read at coreToolScheduler.ts:3002 before evaluateAutoMode and is only forwarded as skipClassifierReason (:3020). Reaching the manual dialog therefore needs a fourth attempt at the same action.
5. The guidance shipped with the block forbids that fourth attempt. AUTO_MODE_DENIAL_GUIDANCE (autoMode.ts:627) is appended to every block message (:558, :664) and tells the model not to retry and to "stop and ask the user for explicit approval" — which is exactly the remedy that link 1 makes unsatisfiable.

The closed loop is real in current main and does not depend on the fork: the gate demands a confirmation → the confirmation is stripped from the gate's input → the advertised remedy cannot satisfy it → the only release requires retrying what the guidance forbids retrying.

One nuance worth adding. Two partial releases exist that the report does not mention, and neither breaks the loop: maxTotalDenials: 20 (denialTracking.ts:40) also triggers shouldFallback, but only after twenty classifier denials; and an L4 permissions.allow match calls recordAllow and clears the streak (coreToolScheduler.ts:2980). Both still arm a future call rather than releasing the blocked one. The allow-rule path is nonetheless the one usable operator workaround today.

Defect 2 — confirmed

1. The mode is runtime state on Config (packages/core/src/config/config.ts:2265), re-derived at construction as params.approvalMode ?? ApprovalMode.AUTO (:2588), with approvalModeRevision starting at 0 (:2267). It is not carried in the persisted session record.
2. The resume path applies a caller-supplied mode only under if (approvalMode) (packages/acp-bridge/src/bridge.ts:5562, applyApprovalMode at :5749), so a session/resume that merely reattaches rebuilds on the built-in default.
3. The reaper defaults are as described: DEFAULT_SESSION_IDLE_TIMEOUT_MS = 30 * 60_000 (bridge.ts:2671) and DEFAULT_SESSION_PROMPT_SETTLED_CLOSE_GRACE_MS = 0 (:2675), consumed by entryIsAutoCloseCandidate (:3121) — the grace that protects poll-based clients between polls is off by default.
4. The second convergence path is real and intentional: foldReloadApprovalMode (packages/cli/src/acp-integration/acpAgent.ts:1867) folds a missing or falsy tools.approvalMode to AUTO, with the in-source rationale that a key deletion should reach live sessions; a present but unparseable value returns undefined and leaves sessions on their current mode.

Not verified

• The incident timeline (6 turns in the caller's mode → ~84 min idle → session_restore → qwen-code.config reporting auto) — we have no access to the reporter's daemon, OTel traces, or fork. The mechanism is confirmed from source; the observed sequence is the reporter's claim, not our evidence.
• That the fork carries no local modifications to these paths — unverifiable from here. All cited files are upstream-owned, which makes the mechanisms verifiable without the fork.
• End-to-end reproduction of a classifier block — not run (unattended CI; the gate does not execute issue-derived code or make live model calls). It is nondeterministic by nature, and we agree the reporter's projection-level test is the tighter artifact.
• No stock-release reproduction — the reporter does not claim one and pasted no /about. That is acceptable here precisely because both mechanisms were established by reading upstream source at a named commit rather than by observing a build.

Assessment

• Split this into two issues. Different subsystems (packages/core/src/permissions vs. packages/acp-bridge + packages/cli/src/acp-integration), different fixes, different reviewers, independently shippable. "Neither is sufficient alone" describes the incident; it does not describe the fixes. Defect 1 is worth landing on its own even if Defect 2 is never fixed, and vice versa.
• Defect 1 — framing is sound, but the change touches a deliberate security boundary. The strip exists because tool results may carry untrusted content (classifier-transcript.ts:12), and Harden AUTO mode against self-modification and denial bypass #4538 hardened this area against bypass. A carve-out must be provably limited to host-committed interactive answers and must not generalize to tool results — the reporter's own proposal says exactly this, which is the right shape. The offered projection unit test is a good first artifact; it should also assert that non-allowlisted tool results stay stripped, so the boundary is pinned by a test and not just by intent.
• There is a smaller half of Defect 1 worth separating. Even without changing what the classifier sees, letting a classifier_blocked verdict on an action that already has a committed interactive confirmation arm the manual-approval dialog directly — instead of requiring a fourth attempt — breaks the loop with a much smaller safety delta than any projection change. If the two halves are separated, that one can move faster.
• Defect 2 is an API-contract decision, not a bug hunt. The reporter's decisive point stands: a client cannot distinguish "drifted on rebuild" from "a human deliberately changed it", so option 1 (persist and restore) alone does not deliver what an integrator needs. Options 2 and 3 are the ones that make the invariant enforceable, and they are cheap — approvalModeRevision (config.ts:2267) already exists as a comparison point and modes.currentModeId is already in the load/resume response, so surfacing a discrepancy needs no new round trip. need-discussion is applied for this decision.
• Interim mitigations that work today, worth recording for anyone else hitting this: qwen serve exposes --session-idle-timeout-ms and --session-prompt-settled-close-grace-ms (wired at packages/cli/src/commands/serve.ts:918), so a poll-based harness can stop its sessions being reaped mid-workflow; re-applying the mode after resume and cross-checking modes.currentModeId catches drift; and for Defect 1, a permissions.allow rule for the specific blocked tool clears the denial streak via recordAllow.

中文说明

本节证据：仅静态阅读源码。 这是无人值守的 CI triage，没有构建或执行任何东西 —— 没有复现、没有真实分类器调用、没有启动 daemon。下面所有行号均在 main@80497a74d0e8 上核对过；相比报告者的 05b8ee06a261 有数行漂移，此处给出的是当前行号。

缺陷 1 —— 确认，链条上五个环节全部成立

1. 答案在构造上就被剥离。 buildClassifierContents（classifier-transcript.ts:98）保留用户文本，把每个 model functionCall 重渲染为 user 轮次 Prior action: name({...})（:215），并丢弃所有 role === 'function' 部分（:145）。这个剥离是有意为之，:12 明确写着"Tool results are fully stripped — they may contain untrusted content"。工具结果是答案唯一的表示形式，所以分类器看不到它。
2. 提问本身完全不进入 denial 状态机。 ASK_USER_QUESTION 在 SAFE_TOOL_ALLOWLIST 里（autoMode.ts:76），且 shouldRunAutoModeForCall 对它提前返回 false（:122，判断在 :127）。调度器的 L5 分支由该谓词把关，因此一次确认往返既不调用 recordAllow 也不调用 recordBlock，中间没有任何东西清零连续计数。
3. blocked 与 unavailable 确实不对称。 applyAutoModeDecision（autoMode.ts:544）中：classifier_unavailable → {kind:'fallback'} → 真正的人工确认弹窗（并附带"Switching to Default Mode is recommended"）；classifier_blocked → {kind:'blocked'} → 给模型的 EXECUTION_DENIED / not_started 工具错误（coreToolScheduler.ts:3072）。block 不产生权限请求，用户无从应答。
4. 逃生通道只对"下一次"生效，对当前这次无效。 maxConsecutiveBlock: 3（denialTracking.ts:38）；shouldFallback（:128）在 coreToolScheduler.ts:3002 于 evaluateAutoMode 之前读取，只作为 skipClassifierReason 传下去（:3020）。因此要走到人工弹窗，需要对同一动作发起第四次尝试。
5. 随 block 一起下发的指引恰好禁止了第四次尝试。 AUTO_MODE_DENIAL_GUIDANCE（autoMode.ts:627）附加在每条 block 消息上（:558、:664），要求模型不要重试、"stop and ask the user for explicit approval" —— 而这正是第 1 条使其无法满足的补救方式。

闭环在当前 main 上真实存在，且不依赖 fork：门禁要求确认 → 确认在门禁输入中被剥离 → 门禁自己宣传的补救方式无法满足它 → 唯一的释放路径要求重试指引禁止重试的动作。

一点补充。 报告未提到两个部分释放路径，但两者都无法打破闭环：maxTotalDenials: 20（denialTracking.ts:40）同样会触发 shouldFallback，但需要二十次分类器拒绝；L4 permissions.allow 命中会调用 recordAllow 清零计数（coreToolScheduler.ts:2980）。两者仍然只是为下一次调用解除限制，而非释放当前被 block 的这次。不过 allow 规则是今天运维侧唯一可用的绕过手段。

缺陷 2 —— 确认

1. 审批模式是 Config 上的运行时状态（config.ts:2265），构造时按 params.approvalMode ?? ApprovalMode.AUTO 重新推导（:2588），approvalModeRevision 从 0 开始（:2267），且不随会话记录持久化。
2. resume 路径只在 if (approvalMode) 下应用调用方传入的模式（bridge.ts:5562，applyApprovalMode 在 :5749），所以仅做重连的 session/resume 会以内置默认值重建运行时。
3. 回收器默认值与描述一致：DEFAULT_SESSION_IDLE_TIMEOUT_MS = 30 * 60_000（bridge.ts:2671）、DEFAULT_SESSION_PROMPT_SETTLED_CLOSE_GRACE_MS = 0（:2675），由 entryIsAutoCloseCandidate（:3121）消费 —— 保护轮询型客户端的宽限期默认关闭。
4. 第二条收敛路径真实且是有意设计：foldReloadApprovalMode（acpAgent.ts:1867）把缺失或假值的 tools.approvalMode 折叠为 AUTO，源码注释说明这是为了让删除配置键能作用到活跃会话；存在但无法解析的值返回 undefined，让会话保持当前模式。

未验证的部分

• 事件时间线（6 轮在调用方模式下 → 约 84 分钟空闲 → session_restore → qwen-code.config 报告 auto）—— 我们无法访问报告者的 daemon、OTel trace 或 fork。机制已由源码确认；观测到的时序属于报告者的陈述，不是我们的证据。
• 该 fork 是否对这些路径没有本地修改 —— 无法从这里验证。所引用文件均为上游所有，因此无需 fork 也能核对机制。
• 分类器 block 的端到端复现 —— 未执行（无人值守 CI；门禁不执行 issue 衍生的代码，也不发起真实模型调用）。它本质上是非确定性的，我们也认同报告者提出的投影层单测是更精确的验证形式。
• 没有正式发行版上的复现 —— 报告者没有声称有，也没有粘贴 /about。这里可以接受，正是因为两个机制都是通过在指定 commit 上阅读上游源码确认的，而不是靠观察某个构建。

评估

• 建议拆成两个 issue。 子系统不同（packages/core/src/permissions 对比 packages/acp-bridge + packages/cli/src/acp-integration）、修复方案不同、评审人不同，且可各自独立发布。"两者单独都不足以导致事故"描述的是这次事故，不是修复工作。即使缺陷 2 永不修复，缺陷 1 也值得单独落地，反之亦然。
• 缺陷 1 —— 框定合理，但改动触及一条有意设置的安全边界。 剥离工具结果的原因是其中可能包含不可信内容（classifier-transcript.ts:12），而 Harden AUTO mode against self-modification and denial bypass #4538 正是针对该区域的绕过做了加固。豁免必须可证明地仅限宿主已提交的交互式答案，不能推广到工具结果整体 —— 报告者自己的提案正是这样写的，方向正确。其提出的投影层单测是很好的第一份产物；该测试还应断言非白名单工具结果仍然被剥离，让这条边界由测试固定，而不只是靠意图。
• 缺陷 1 有一个更小的部分值得单独拆出。 即便不改变分类器能看到什么，只要让一个已经存在已提交交互式确认的动作在收到 classifier_blocked 时直接触发人工确认弹窗 —— 而不是要求第四次尝试 —— 就能打破闭环，其安全影响远小于任何投影层改动。如果两半分开，这一半可以更快推进。
• 缺陷 2 是 API 契约决策，不是排查工作。 报告者的关键论点成立：客户端无法区分"重建时漂移"与"人类主动修改"，因此仅靠方案 1（持久化并恢复）无法给集成方真正需要的东西。方案 2 和方案 3 才能让该不变量可被强制，而且成本很低 —— approvalModeRevision（config.ts:2267）已经是现成的比较点，modes.currentModeId 也已在 load/resume 响应中，暴露差异不需要额外往返。need-discussion 正是为这个决策而加。
• 今天可用的临时缓解措施，值得记录给其他遇到此问题的人：qwen serve 提供 --session-idle-timeout-ms 与 --session-prompt-settled-close-grace-ms（接线在 packages/cli/src/commands/serve.ts:918），轮询型 harness 可以借此避免会话在工作流中途被回收；resume 后重新设置模式并交叉校验 modes.currentModeId 可以发现漂移；针对缺陷 1，为具体被 block 的工具添加 permissions.allow 规则可通过 recordAllow 清零 denial 计数。

--- Qwen Code