Background task notifications cancel pending permission requests with a message that impersonates the user

Independent corroboration on Windows, plus binary-level evidence for the wording half of this report.

Environment

• Claude Code 2.1.231, Windows 10 (claude-code-win32-x64), and the same constant in the Nimbalyst-bundled @anthropic-ai/claude-agent-sdk-win32-x64 copy
• Background subagents launched via the Agent tool with run_in_background: true
• No deny rules configured; permissions.defaultMode: "auto"

Existing repros here are macOS (#88203) and Linux (#78288) — adding Windows, so this is all three platforms.

What happened

Five background subagents across one session. Every one of them died, and three subsequent tool calls (two Agent launches, one internal tool-schema load) came back as:

The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed.

The operator did nothing. He was on his phone, and the first he knew of any of it was the agent telling him he had blocked it. The agent then wrote him two formal BLOCKED ON: <decision> messages asking him to choose how to proceed — from a decision he had never made. Two full turns produced zero deliverable while the agent re-litigated a permission that was never actually denied.

That is the same escalation loop described in the original report, and it is worth emphasizing that the damage is not only the cancelled call. The model treats the sentinel as ground truth about the user's intent and reasons downstream from it — it stops, apologizes, asks the human to unblock something the human never blocked, and discards work.

The wording asymmetry (new evidence)

The sentinel is a compile-time constant in the shipped binary. From claude.exe (2.1.231):

"[Request interrupted by user]"
"[Request interrupted by user for tool use]"
Yj = "The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed."

Yj sits in the same minified block as the two interrupt sentinels — i.e. it is the generic reject/interrupt fallback.

Meanwhile the other denial sources in the same binary already attribute themselves correctly:

case "hook": return t.reason
  ? `Hook '${t.hookName}' blocked this action: ${t.reason}`
  : `Hook '${t.hookName}' requires approval for this ${e} command`;
case "rule": { ... }

So hook denials name the hook and give a reason. Rule denials name the rule. Only the fallback path — the single case where the cause is genuinely unknown — asserts a specific human intent. It is the one message that cannot know what it claims, and it is the only one phrased as a first-person statement about the user.

Suggested fix for the wording half

Independent of the queue/abort race (#86650, #88203), the sentinel should not claim to know why the call stopped. Something like:

Action denied; source unattributed. May be an interrupt rather than a decision. Do not infer user intent.

That is 98 characters against the original's 118, so it is a drop-in replacement.

This is worth decoupling from the race fix, for two reasons:

1. It is a much smaller change with independent value. Even after the race is fixed, timeouts (#78288), transport loss (#79246), and abort-controller reuse (#86650) all funnel into this same string. Every one of them currently reports as a user refusal.
2. It converts a silent, compounding failure into a visible one. Today the model has no way to distinguish "the human declined" from "something broke," so it confidently misattributes to the human and stops. With neutral wording it would retry, route around, or report honestly.

A machine-readable source field on the error (user | hook | rule | timeout | transport | unknown) would be better still, and would let agent harnesses handle the unattributed case explicitly rather than parsing prose.

Why this matters beyond the lost tokens

The operator's reaction on being shown the root cause was, verbatim: "Can you change the wording from 'The user doesn't want to take this action'?!?! 'Action denied'? With a reason...?"

The current string does not just misinform the model. It manufactures a false record of a user decision, in the user's own voice, in their transcript — and the agent then argues back to them from it.

Seeing this on a ubuntu sandbox too.

It's pretty nasty - it poisons the entire session so any future tool calls get blocked as if the user cancelled them.

Exactly!  This is incredibly bad!On 26 Aug 2026, at 12:16, csaunders-ldt @.***> wrote:csaunders-ldt left a comment (anthropics/claude-code#85408)
Seeing this on a ubuntu sandbox too.
It's pretty nasty - it poisons the entire session so any future tool calls get blocked as if the user cancelled them.

—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you commented.Message ID: @.***>

Hey — your Claude Agent SDK issue around background tasks cancelling permission requests caught my attention.

I'm experimenting with separating the policy decision from the agent's conversational state so that approval isn't dependent on the model/runtime getting the surrounding interaction exactly right.

I'd love to see whether that architecture helps with any of these edge cases.

If you're interested, I'll help install the prototype for free against a small workflow. All I'd ask is honest feedback after you've tried it — particularly whether the separation makes things safer or just more complicated.