Add "Yes, for this session" option to permission prompts

Resolved 💬 3 comments Opened Apr 9, 2026 by gitguy225 Closed Apr 13, 2026

### Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

### Problem Statement

The current permission prompt offers two extremes:

  1. Yes — one-time allow, forgotten immediately
  2. Yes, and don't ask again — permanently persisted to settings.local.json

There is no middle ground. When working on a task that requires repeated use of a command pattern (e.g., git commit, git push, compound shell commands), users must either:

  • Click "Yes" every single time (tedious, breaks flow)
  • Click "Yes, and don't ask again" which permanently allows the pattern, then manually clean up settings.local.json afterward if they didn't want a permanent rule

This is especially painful for compound commands (e.g., compile && git add && git commit && git push) where the permission prompt fires once for the full command, but the user only wants to allow it for the duration of their current work session.

### Proposed Solution

Add a third option to the permission prompt:

Do you want to proceed?
❯ 1. Yes

  1. Yes, and don't ask again for in
  2. Yes, for this session
  3. No

Option 3 ("Yes, for this session") would:

  1. Approve the command immediately
  2. Store the allow rule in memory only (not written to any settings file)
  3. Apply the rule for the remainder of the current Claude Code process
  4. Be automatically discarded when the process exits

### Why this is distinct from #11073

Issue #11073 proposed cycleable scopes for the "don't ask again" option (local project → user → project settings). That feature cycles between persistent storage destinations. This request is for an ephemeral tier that is never persisted — a fundamentally
different behavior.

### Implementation notes

The codebase already has a destination: "session" concept for file path permissions (observed in the compiled source). Extending this to Bash command permissions and other tool types should be straightforward — the infrastructure for in-memory-only allow rules
appears to exist.

### Priority

Medium - Would be very helpful

### Feature Category

Interactive mode (TUI)

### Use Case Example

Iterative compile-commit-push cycle:

I'm iterating on a CI workflow fix. Each cycle requires:
gh aw compile .github/workflows/foo.yml && git add ... && git commit -S -m "..." && git push origin branch

I want to approve this pattern once and keep working without interruption for the rest of my session. But I don't want this broad compound command pattern permanently saved — next session, I'd like Claude to ask again since the context will be different.

Session-scoped MCP tool access:

When debugging, I might need repeated access to an MCP tool (e.g., database queries, observability tools). I want to allow it for the debugging session without creating a permanent rule.

### Additional Context

Current workaround: use option 2 ("don't ask again"), then manually remove the generated pattern from .claude/settings.local.json after the session. This is error-prone and easy to forget.

View original on GitHub ↗

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