[FEATURE] Task-scoped permission approval — "Yes for this task

Resolved 💬 3 comments Opened Apr 6, 2026 by FHavens Closed Apr 7, 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

Problem

Currently, Claude Code offers binary permission approval:

  • "Yes" — allows a single tool call
  • "Yes for session" — allows all identical tool calls for the entire conversation

For longer conversations with multiple distinct tasks, the middle ground is missing.
Users either tap through repetitive approvals within a task, or grant blanket session
approval they may not want for unrelated work later in the same conversation.

Current workarounds

None ideal:

  • "Yes" per call — high friction for repetitive edits within a task
  • "Yes for session" — over-permission, no gate for later unrelated work
  • No middle ground exists via CLAUDE.md, settings, hooks, or custom commands

Proposed Solution

Add a task-scoped approval option: "Yes for this task" whenever a defined task is triggered. For example: [Task] { prompts } In Claude.md, Command, or Interactive Prompt (if possible)

This would allow tools (e.g. Any Non-read tools such as edit, read, etc.) to skip the prompts for the duration of the current logical task, then automatically expire when the user moves to a new task.

Alternative Solutions

Provides limited benefit compared to the proposed, and is file based, but will reduce friction.

Add a task-scoped approval option: "Yes for this task" whenever the file is going to be updated (or any non-read action).
If option selected and file is repeatedly (sequentially) accessed, the options are not presented.

This will allow multiple sequential tools against the same file without getting the option prompt again.
Once the target file is different, the task is considered completed and option prompt is shown.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

Any multi-task session where the same file is edited repeatedly within a task but
shouldn't be auto-approved across tasks:

  • Sprint workflow: Updating a storyboard document with status changes and detail

edits for Task A (multiple edits, same file), then moving to Task B which touches
different files — returning to the storyboard later for Task B's updates should
re-prompt

  • Multi-file refactors: Approving edits across a set of related files for one

feature, then switching to a separate feature in the same session

  • Documentation updates: Batch-approving edits to a spec document for one section,

then re-prompting when a different section is touched for a different reason

Additional Context

Task boundary options

  • Explicit: User marks boundaries via a command, prompt, or claude described tasks
  • Implicit: Tied to TodoWrite task transitions (in_progress → completed) or

similar task-tracking signals

  • Configurable in settings.json or .claude/settings.json

View original on GitHub ↗

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