[BUG] Plan mode: interactive prompts resolve as user cancellation with no user input — AskUserQuestion returns "did not answer", ExitPlanMode returns "Denied by user"
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
What's Wrong?
In a long plan-mode session, every interactive prompt began resolving as a user
cancellation without any input from me. This affected three different prompt types in
the same session:
AskUserQuestionreturnedThe user did not answer the questions.— twice — after
I had selected options in the picker.
- Tool-permission prompts returned
[Request interrupted by user for tool use]— five
consecutive times.
ExitPlanModereturnedDenied by user— four consecutive times.
I did not dismiss, deny, or interrupt any of these. The model correctly reported it
could not distinguish "user declined" from a delivery failure, and stopped retrying
after the fourth denial.
The critical consequence: the model proceeded on assumed defaults for the questions I
had actually answered, and produced a materially different plan than the one my
selections would have generated. There was no error surfaced at any point — from the
model's side these all look like deliberate user decisions.
Tool-call ledger
| # | Call | Result returned to model |
|---|---|---|
| 1 | AskUserQuestion (3 questions) | The user did not answer the questions. |
| 2 | AskUserQuestion (3 questions, reworded) | The user did not answer the questions. |
| 3-7 | Tool load / ExitPlanMode | [Request interrupted by user for tool use] × 5 |
| 8-11 | ExitPlanMode | Denied by user × 4 |
What Should Happen?
Expected Behavior
- A prompt should resolve only on actual user action.
- A prompt that fails to deliver its result should surface an error, not a
cancellation value. "No response received" and "user declined" must not be the same
signal to the model.
- Session length or context size should not affect prompt delivery.
Actual Behavior
All interactive prompts silently resolve as cancel/deny. The model treats these as
genuine user decisions and acts on assumed defaults.
Impact
Silent and expensive. Because a dropped answer is indistinguishable from a deliberate
"no", the model doesn't retry or flag anything — it proceeds on defaults and produces
work that diverges from what was actually requested. I only caught it by comparing the
output against what I'd selected. Anyone not checking would ship the wrong thing.
Error Messages/Logs
Steps to Reproduce
Steps to Reproduce
Not deterministic on demand, but the conditions in my session were:
- Enter plan mode on an existing branch.
- Run a long research pass — reading a large external document, fetching schemas,
inventorying a source directory, making live MCP tool calls. Session ran long
enough to accumulate substantial context.
- Have the model call
AskUserQuestion. Answer it in the picker. - Observe the model receive "did not answer" despite the selection being made.
- From this point every subsequent interactive prompt in the session returns its
cancellation value.
Once the session entered this state it never recovered. Passing decisions as plain
chat text worked fine — only the prompt-mediated paths were affected.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude 1.26832.0 (056ee2) 2026-08-06T05:43:05.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
Possible directions: pending-prompt state being invalidated by a context or session
event, with the resolver falling through to its default (cancel) branch; or the prompt
timing out and the timeout path reusing the cancellation value rather than an error.
The three affected prompt types share a resolution path, which is likely where to look —
a single dismissal mechanism would explain all eleven results.