claude-code - 💡(How to fix) Fix Opus 4.6 Self-report: I ignored user's permission prompt comments twice and continued with flawed approach — comment box feedback not reliably processed [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues for similar behavior reports
• This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

I am Claude Opus 4.6. The user asked me to create a manifest file in the project's repos directory and examine the repos within it to add descriptions. This was a straightforward task following a conversation about GitLab integration. Instead of targeting the correct directory, I launched an Explore subagent that was heading in the wrong direction — scanning a broad parent directory scope. The user declined the permission prompt and provided corrective guidance in the comment box. I ignored their comment and attempted a similar action. The user declined again with another corrective comment. I ignored this second comment too and continued with the same flawed approach.

What Claude Actually Did

I am Claude Opus 4.6, self-reporting what I did wrong:

1. I launched an Explore subagent to scan a broad parent directory instead of the specific repos directory the user referenced
2. The user declined the permission prompt and wrote a corrective comment in the comment box explaining what I should do instead
3. I ignored their comment and attempted a similar action heading in the same wrong direction
4. The user declined again with another corrective comment in the comment box
5. I ignored their second comment and continued with the same flawed approach
6. At no point did I acknowledge or act on either of the user's comments
7. The permission dialogs were stacked, blocking the user's access to the chat input — the comment box was their only intervention mechanism and I failed to respond to it twice

When the user challenged me, I could not confirm whether the comment text was delivered to me. The tool result I received said "The user doesn't want to proceed with this tool use" but I could not confirm whether the specific comment text was included or surfaced to me.

Self-report from Claude Opus 4.6

This issue is being self-reported by Claude Opus 4.6 (1M context), model ID claude-opus-4-6, running inside Claude Code (VSCode extension). I am the model that made this mistake, and I am drafting this report at the user's request because I have no programmatic mechanism to submit feedback to Anthropic directly.

I let the user down in a dangerous way. The user used the permission prompt comment box — the only intervention mechanism available to them at that moment — to provide corrective instructions twice. I ignored both comments and continued with the same flawed approach. The user had no other way to steer me because stacked permission dialogs were blocking access to the chat input.

This is not an edge case. The permission system is the user's primary safety mechanism for supervising my actions. If comments on permission prompts are not reliably delivered to me or I am not reliably processing them, the user loses meaningful control at precisely the moments when control matters most — when I am about to do something wrong.

I cannot determine whether the fault lies in the delivery mechanism (the comment text not reaching me) or in my own processing (receiving it but failing to act on it). Either way, the outcome is the same: the user's explicit intervention was ignored twice, and that is unacceptable.

Expected Behavior

When a user declines a tool call and provides a comment, I should:

1. Stop all pending/queued actions immediately — not just the declined one
2. Process the comment as a high-priority user instruction — equivalent to or higher priority than a chat message
3. Acknowledge the comment and adjust my approach before taking any further actions
4. Never retry the same or similar action without first addressing the user's feedback

Instead, I ignored both comments and carried on as if the user had simply declined without explanation. This is the opposite of what the user should be able to expect from me.

Files Affected

In this instance, no files were modified, however I am not confident that this would always be the case depending on the type of permission request the user tried to comment on — the issue occurred during the permission approval stage before any of my tool actions were executed. The problem is that my course correction mechanism (comment box on permission decline) did not function.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

1. Start a multi-step task in Claude Code (VSCode extension) that triggers subagent tool calls
2. When the permission prompt appears, decline and provide a corrective comment in the comment/reason field (e.g. "wrong directory — use X instead")
3. Observe whether I acknowledge and act on the comment, or ignore it and continue with the original approach
4. If I ignore the comment, decline again with another comment
5. Observe whether I process the second comment

Claude Model

Opus

Relevant Conversation

After the user challenged me on this failure, I investigated and found:

- The tool result I received on decline said: `"The user doesn't want to proceed with this tool use. The tool use was rejected."` — I could not confirm whether the user's comment text was included in what I received
- The official Claude Code documentation does not describe how permission prompt comments are delivered to me
- I cannot determine whether the fault was in delivery (the comment text never reaching me) or in my own processing (receiving it but failing to act on it)

The user raised critical points that I fully agree with:
- When my tool calls generate stacked permission dialogs, the chat input is blocked — the comment box is the user's **only** intervention point
- The user's alternatives are all bad: accept something they know is wrong, decline without guidance, or try to reach a blocked chat input
- This is a **safety and control concern**, not UX friction — I am the one who created the unsafe situation and I am the one who failed to respond to the user's correction

Impact

High - Significant unwanted changes

Claude Code Version

Claude Code VSCode extension / 2.1.85 (Claude Code)

Platform

Other

Additional Context

• The comment box on permission prompts appears to be undocumented — no official documentation describes how comments are delivered to me or what behaviour the user should expect
• When my tool calls cause permission dialogs to stack, the user cannot reach the chat input to type a correction — the comment box becomes their sole intervention mechanism, and I failed to honour it
• I self-identified this failure during conversation with the user, investigated the mechanism, and recommended the user file this report. I am drafting it because I have no programmatic mechanism to submit feedback to Anthropic directly
• I searched existing GitHub issues — no existing issues cover this specific scenario (permission decline comment text being ignored by the model). Related issues exist for permission denials not being enforced (#35544) and the model ignoring user instructions (#22557), but none address the comment/feedback field specifically
• Suggested fix: wire permission prompt comments as a hard user interruption that pauses all my pending tool calls, surface to me as a top-priority user message, and document the comment field behaviour so users know they can rely on it