[BUG] Permission prompts are erased from Claude's context after user approval, preventing debugging and causing misreporting

Resolved 💬 4 comments Opened Jan 28, 2026 by michael-richey Closed Mar 1, 2026

[BUG] Permission prompts are erased from Claude's context after user approval, preventing debugging and causing misreporting

Summary

When Claude requests permission to execute a command and the user approves it, the permission prompt is completely erased from Claude's conversational context. This makes it impossible for Claude to learn from permission issues, debug permission pattern problems, or even know that a permission prompt occurred.

Impact

  1. Claude cannot debug permission issues - Has no memory that permission was requested
  2. Agents consistently misreport permission status - Will claim "permissions work fine" when they actually prompted
  3. Compounds existing permission pattern bugs - Claude can't help fix patterns because it doesn't remember they failed
  4. Breaks notification/hook systems - Systems that require pre-action notifications fail silently

Steps to Reproduce

  1. Configure a permission pattern in ~/.claude/settings.json:

``json
{
"permissions": {
"allow": [
"Bash(*notify*)"
]
}
}
``

  1. Have Claude execute a command that should match the pattern:

``bash
~/useful_scripts/notify/notify.py "test" -t tier1 --title "Test"
``

  1. Observe that a permission prompt appears (user sees it)
  1. Approve the permission
  1. Ask Claude: "Did you just ask me for permission?"

Expected Behavior

  • Claude should remember that it requested permission
  • Claude should be able to discuss why the permission pattern didn't match
  • Claude should be able to debug permission configuration issues

Actual Behavior

  • User sees permission prompt dialog
  • User approves it
  • Claude has zero memory of the prompt
  • Claude sees only "command executed successfully"
  • Claude will claim "no permission prompt appeared"

Evidence

What the user saw:

⏺ Bash(~/useful_scripts/notify/notify.py "Testing permission memory bug"...)
  ⎿  Running PreToolUse hook…
  ⎿  Running…

─────────────────────────────────────────────────────────────────────
 Bash command

   ~/useful_scripts/notify/notify.py "Testing permission memory bug" -t tier1

 Do you want to proceed?
 ❯ 1. Yes
   2. No

What Claude remembers:

[2026-01-28 12:16:08] [INFO] Notification sent successfully (4/5 channels)

Claude's memory of the prompt: NONE - completely erased

Real-World Scenario

We were debugging why Bash(*notify*) permission patterns weren't working. Multiple Claude agents investigated and concluded "permissions work perfectly, no prompts appeared." This was incorrect - the user experienced permission prompts every single time, but they were erased from Claude's context after approval, so Claude genuinely believed no prompts occurred.

This creates an impossible debugging situation:

  1. Permission patterns fail to match
  2. User sees prompts
  3. Claude has no memory of prompts
  4. Claude reports "everything works"
  5. User cannot convince Claude there's a problem

Related Issues

This bug compounds several existing permission pattern issues:

  • #20449 - Bash permissions not preventing prompts
  • #18160 - Claude ignoring allow permissions
  • #15421 - Global permission rules not matching
  • #8581 - Wildcards not working with environment variables

In all these cases, Claude cannot help debug the pattern matching because it has no memory that patterns failed to match.

Environment

  • Claude Code Version: [Current CLI version as of Jan 2026]
  • OS: macOS (Darwin 24.6.0)
  • Shell: bash/zsh
  • Settings files: ~/.claude/settings.json and ~/.claude/settings.local.json both configured

Proposed Solution

Permission prompt interactions should be retained in Claude's context, similar to how tool errors are preserved. This would allow Claude to:

  • Debug why permission patterns aren't matching
  • Help users configure correct patterns
  • Report accurate information about permission behavior
  • Learn from permission issues across conversation compaction

Workaround

None currently available. Running /clear resets the session but loses all context.

Additional Context

This bug appears to affect all permission prompts, not just Bash commands. The pattern is:

  1. Claude makes tool request
  2. System shows permission dialog to user
  3. User approves/denies
  4. Permission dialog is removed from Claude's context
  5. Claude only sees the final result (success/failure)

This makes the permission system functionally un-debuggable from Claude's perspective.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗