[FEATURE] Unified "Pending Approvals" panel for multi-worktree / multi-session workflows

Status Open
Maintainer reply None cached
Activity 1 comment · opened Jul 31, 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

I regularly work across multiple git worktrees of the same project, each running its own Claude Code session/chat in the desktop app. Every session independently prompts for command approval, so when several worktrees are working in parallel, I have to click into each chat individually to check whether it's blocked on a permission prompt and approve it there.

There's no way to see, from one place, which of my open sessions are currently waiting on approval. In practice this means:

Switching between chat tabs just to check if anything is blocked
Losing track of which worktree a pending prompt belongs to
Parallel work effectively serializing, since I can only approve one prompt at a time by hunting for it

The existing repo-wide allowlist (.claude/settings.local.json, resolved through worktrees to the main checkout) helps for repeated commands I've already approved once, but it doesn't help with the first approval, or with commands that legitimately vary between worktrees and shouldn't be blanket-allowlisted.

Proposed Solution

Add a persistent, collapsible "Pending Approvals" panel docked to the right side of the desktop app window, similar to a notifications drawer. It would:

List every command/tool-use currently awaiting approval across all open chats and worktrees, not just the active one
Show the worktree/branch name and the command for each pending item
Let the user Allow, Allow always, or Deny directly from the list, without switching to that chat
Optionally jump to the source chat on click, for cases where more context is needed before deciding

Rough sketch:
<img width="305" height="352" alt="Image" src="https://github.com/user-attachments/assets/64736043-b97c-4f69-9ebc-5c6b0fa3f920" />

Alternative Solutions

  • Manually switching between chat tabs to find and approve pending prompts
  • Pre-populating .claude/settings.json / settings.local.json with allowlisted patterns to reduce prompt frequency, which only covers commands known in advance
  • Considered --dangerously-skip-permissions / Bypass permissions mode, but that removes review entirely rather than just centralising it

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Example scenario:

  1. I'm working on a feature branch and have created 3 git worktrees for it — one for the main feature, one for a bugfix, one for a refactor — each opened as its own Claude Code chat in the desktop app.
  2. I kick off work in all three simultaneously so they can run in parallel.
  3. Each session hits a command it needs approval for (e.g. a migration script, a kubectl apply, a rm -rf on a build folder) at different times.
  4. Right now I have to keep switching between chat tabs just to notice which ones are blocked, then click into each one individually to approve or deny.
  5. With a unified "Pending Approvals" panel on the right side of the app, I'd see all 3 pending prompts in one list — labeled by worktree/branch and could approve or deny each without leaving my current chat.
  6. This would let me actually run worktrees in parallel instead of the approval flow forcing me to babysit one chat at a time.

Additional Context

  • Mockup: a collapsible right-side panel showing each pending command, its source worktree/branch, and inline Allow / Allow always / Deny buttons, with a click-through to the originating chat for more context.
  • Related: .claude/settings.local.json already allowlists repeated commands repo-wide across worktrees, but this doesn't help with first-time approvals or commands that intentionally vary between worktrees.
  • Considered --dangerously-skip-permissions / Bypass permissions mode as a workaround, but that removes review entirely rather than just centralizing it.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗