[FEATURE] Add /queue-permissions for async permission queuing with intelligent task switching for productivity optimization

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 9, 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 problem: There is a massive inefficiency with permission prompts halting all progress. I would run /goals against a detailed plan md file and it would ask permissions throughout executions but sometimes I'm reading or paying attention to something else or communicating with others and the progress on a goal stays halted wasting critical time. /remote-control is a mode to help with this generic inefficiency issue if the user is not at their desk, but this inefficiency occurs even when at the desk while attention is not fully given to Claude code.

A similar frustration was pointed out in issue #55769, the issue was closed due to inactivity however and discusses other extra solutions.

Proposed Solution

The idea: Add a mode _/queue-permissions_ where instead of halting progress, the model reasons within the scope of the requested work and finds the next best task that has the least impact related to the current permission that the model needs. Essentially spawning a background agent to search other stuff to do while blocked on permissions. Once a task is found, it continues work down that working path, essentially automating a message for "_tell claude what to do instead_" with "_user unavailable, perform other work within scope and ask Permission 1 when the user indicates they are back to sign off permissions to continue your previous work, halt only if there are no independent tasks to run_". When the user is available, they will see that there are pending permissions, after approving each one and submitting, the model will then continue the work sequentially on the permission order or whatever the best course of action is in case a decisions demand rework.

The risk: This is essentially a "_use tokens no matter what, dont stop working_" approach, it will be up to users to make educated decisions on whether to use this feature scoping work carefully, otherwise it devolves to "/loop make my app" and 100 permissions that a user has to go through. When used effectively with scoped goals, it's akin to a junior working on as many separate tasks within a generic goal until their senior comes around and unblocks them on several tasks in one meeting.

Alternative Solutions

There are no workarounds, it's just a matter of always being ready to hit the correct decision on a permission prompt. The only thing I can do is my best at multitasking when I have other things I am looking into on another screen or even within the code and I need to lock in.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

9:00 AM: /goal run phase A for my feature based on GOALS.md /queue-permissions

9:10 AM: Needs Permission 1 for Step 1 of phase A
(user researching on another screen)
(Here the model reasons that Step 2 is available to execute independent of Step 1, queue Permission 1)

9:30 AM: Needs Permission 2 for Step 2 for phase A (independent on Step 1)
(discussing with team)
(Here the model reasons that Step 3 is available to execute independent of Step 1 and 2, queue Permission 2)

9:50 AM: Needs Permission 3 for Step 3 for phase A (independent on Step 1 and 2)
(writing up tasks for interns)
(Here the model sees that there cannot be more work done at this point, Permissions 1, 2, and 3 are all pending)

10:05 AM: User comes back, sees progress on all steps but blocked by 3 permission requests, grants all

The task, instead of proceeding with Step 1, will continue Steps 1, 2 and 3 in one go and the next thing the user sees is "Phase A completed" instead of "Needs Permission 2", significant time saved.

Additional Context

<img width="727" height="743" alt="Image" src="https://github.com/user-attachments/assets/065292fe-8cf9-4998-b1c7-b0c74e66f6b7" />

View original on GitHub ↗