Feature request: Permission decision audit log

Resolved 💬 3 comments Opened Mar 25, 2026 by christiangw Closed Mar 29, 2026

Problem

When configuring permission allow-lists in .claude/settings.local.json, there's no way to verify that rules are working as expected. Users configure glob patterns like Bash(gh*) expecting auto-approval, but still get prompted — and there's no diagnostic information to understand why.

What's missing

  1. No audit log — There's no record of which permission rule matched (or didn't match) for each tool call. Users can't tell if their glob pattern failed to match, or if a different check (e.g., protected directory) short-circuited before rule evaluation.
  1. No visibility from the agent side — The AI agent only sees "tool call sent" and "result received." It cannot distinguish between time spent waiting for user approval vs. actual execution time. This means the agent can't even help diagnose permission issues.
  1. No way to debug intermittent prompts — Permission prompts appear to be intermittent for some users (possibly related to #35646 / #36887), making them hard to reproduce and report.

Proposed Solution

Add an opt-in permission audit log, e.g., ~/.claude/logs/permissions.log or a --log-permissions flag, that records each permission decision:

[2026-03-25T14:32:01Z] TOOL=Bash CMD="gh issue view 882 ..." RULE_MATCHED="Bash(gh*)" DECISION=auto-approved
[2026-03-25T14:32:01Z] TOOL=Bash CMD="for i in 883 ..." RULE_MATCHED=none DECISION=prompted RESPONSE=approved WAIT_MS=4200
[2026-03-25T14:32:05Z] TOOL=Write PATH=".claude/foo.json" RULE_MATCHED="Write" DECISION=blocked:protected-directory

Fields could include:

  • Timestamp
  • Tool name and key parameters (command string, file path, etc.)
  • Which allow rule matched (if any)
  • Whether a protected-directory or other check intercepted before rule evaluation
  • Decision: auto-approved, prompted, denied, blocked
  • For prompted decisions: user response and wait duration

Why This Matters

Permission configuration is a key productivity feature — users set up allow-lists specifically so they can kick off work and walk away. When prompts appear unexpectedly, the entire session blocks. Without diagnostic tooling, users can't tell whether their config is wrong, whether there's a platform bug, or whether a different check is overriding their rules.

This is especially important for users running multiple parallel Claude Code sessions (e.g., via git worktrees), where a blocked prompt in one session can go unnoticed.

Environment

  • Platform: macOS (Darwin 25.3.0)
  • Claude Code version: 2.1.74
  • Permission mode: Custom allow-list in .claude/settings.local.json

View original on GitHub ↗

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