Add "Yes, for this session" option to permission prompts
### 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:
- Yes — one-time allow, forgotten immediately
- 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.jsonafterward 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
- Yes, and don't ask again for in
- Yes, for this session
- No
Option 3 ("Yes, for this session") would:
- Approve the command immediately
- Store the allow rule in memory only (not written to any settings file)
- Apply the rule for the remainder of the current Claude Code process
- 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗