[BUG] Session-scoped permission grants cannot be revoked by the user who granted them

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?

Summary

When Claude Code's approval prompt presents the option "Yes, and don't ask again for this session" for a tool use (e.g. Edit, Write), picking it grants a
session-wide auto-approval for that tool type. There is no in-session mechanism for the user to revoke that grant. The only recourse is /exit and restart. This
breaks a basic symmetry — a permission the user set should be unset-able by the same user.

Steps to reproduce

1. Start a Claude Code session.
2. Ask Claude to edit a file. The harness prompts for approval.
3. Select option 2 ("Yes, and don't ask again for this session").
4. Later in the same session, decide you want the "ask every time" behavior back.
5. Try to find a way to revoke the grant.

Observed

• /permissions lists only the persistent rules stored in settings.json / .claude/settings.local.json. The session-only grant is not present in that UI and cannot be

removed through it.

• Adding a deny/ask rule via /permissions takes effect for future sessions only; the current session's in-memory grant continues to override it.
• Editing settings files directly has the same limitation — the in-process grant is not reread.
• No slash command, no REPL affordance, no config reload path clears the grant.
• Only /exit and restarting Claude Code clears it.

What Should Happen?

The user who granted the session-scoped permission can revoke it from within the same session. For example:

• /permissions surfaces in-session grants alongside persistent ones, with a revoke action, or
• a dedicated command such as /permissions revoke <tool> or /permissions reset-session clears all in-session grants, or
• the approval prompt offers an inverse option (e.g. /reapprove) when a tool is currently auto-approved by a session grant.

Why this matters

This is not a request that all internal process state be exposed. Most of it shouldn't be — transcripts, MCP handles, conversation memory, etc. are implementation
detail. The narrow principle is: state the user explicitly set through an interactive prompt should be undoable through some interactive affordance. Permissions are
precisely that class of state — they are user-authored security decisions, and the user should retain control over them for the life of the session, not just the
moment of granting.

Concrete case: a user grants a session-scoped edit approval while working on one task (where confidence in the upcoming edits is high). Later in the same session the
user pivots to a different area where they want tighter supervision. Today, they must tear down the whole session — losing conversation context, task state, and any
in-memory work — to restore "ask before editing" behavior. That's a high cost to pay for what should be a one-click change.

Environment

• Claude Code (CLI, current release)

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session.
2. Ask Claude to edit a file. The harness prompts for approval.
3. Select option 2 ("Yes, and don't ask again for this session").
4. Later in the same session, decide you want the "ask every time" behavior back.
5. Try to find a way to revoke the grant.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

4.7

Claude Code Version

2.1.116

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_