Problem

When a user approves a tool invocation with "Allow" or "Allow for this session" (as opposed to "Allow always"), the permission grant is stored only in process memory. There is:

• No command to list which transient permissions are currently active
• No log recording that the approval happened
• No way to revoke a session-level permission without restarting the session

This means there is a class of security-relevant state that is completely opaque to the user. You cannot answer the question: "What have I authorized Claude to do in this session?"

Expected Behavior

Users should be able to inspect, audit, and revoke transient permission grants.

Proposed Changes

1. /session-permissions command — List all active session-level approvals (tool name, args/pattern, timestamp, scope)
2. Permission audit log — Write every allow/deny decision (transient and persistent) to a local file (e.g. ~/.claude/audit.log) with timestamp, tool, input, and project context
3. Revocation support — A /revoke command or UI to selectively withdraw session-level approvals without restarting
4. PermissionDecision hook event — Emit a hook event when permissions are granted/denied so external tools (SIEM, audit systems) can observe state changes
5. CLI status indicator — Show count of active session permissions in the status bar

Why This Matters

• Security posture visibility — Users managing sensitive codebases need to understand what's been authorized
• Compliance/audit — No audit trail exists for the most common permission grant type (session-level)
• Least privilege — Without revocation, a mistaken "Allow for session" persists until restart
• Incident response — If a session is compromised, there's no way to determine what was authorized

Reproduction

1. Start a Claude Code session
2. Run a command that requires approval (e.g. a Bash command)
3. Click "Allow" (session-level)
4. Try to find where that approval is recorded — it doesn't exist on disk or in any queryable interface