Add feature request: Enable auto-mode option in permission dialogs

When auto mode gets disabled, users face an avalanche of permission
requests without an easy way to re-enable auto mode. This feature
request proposes adding an 'Enable auto-mode' option to permission
dialogs that would approve the current request and re-enable auto
mode for the session.

This addresses the UX pain point where users need uninterrupted time
to manually re-enable auto mode while being bombarded with prompts.

.claude/commands/dedupe.md

@@ -13,7 +13,7 @@ To do this, follow these steps precisely:
 4. Next, feed the results from #1 and #2 into another agent, so that it can filter out false positives, that are likely not actually duplicates of the original issue. If there are no duplicates remaining, do not proceed.
 5. Finally, use the comment script to post duplicates:
    ```
-   ./scripts/comment-on-duplicates.sh --base-issue <issue-number> --potential-duplicates <dup1> <dup2> <dup3>
+   ./scripts/comment-on-duplicates.sh --potential-duplicates <dup1> <dup2> <dup3>
    ```
 
 Notes (be sure to tell this to your agents, too):

.claude/commands/triage-issue.md

@@ -20,7 +20,7 @@ TOOLS:
   - `./scripts/gh.sh issue list --state open --limit 20` — list issues
   - `./scripts/gh.sh search issues "query"` — find similar or duplicate issues
   - `./scripts/gh.sh search issues "query" --limit 10` — search with limit
-- `./scripts/edit-issue-labels.sh --issue NUMBER --add-label LABEL --remove-label LABEL` — add or remove labels
+- `./scripts/edit-issue-labels.sh --add-label LABEL --remove-label LABEL` — add or remove labels (issue number is read from the workflow event)
 
 TASK:
 
@@ -48,15 +48,15 @@ TASK:
    The goal is to avoid issues lingering without a clear next step.
 
 7. Apply all selected labels:
-   `./scripts/edit-issue-labels.sh --issue ISSUE_NUMBER --add-label "label1" --add-label "label2"`
+   `./scripts/edit-issue-labels.sh --add-label "label1" --add-label "label2"`
 
 **If EVENT is "issue_comment" (comment on existing issue):**
 
 4. Evaluate lifecycle labels based on the full conversation:
    - If the issue has `stale` or `autoclose`, remove the label — a new human comment means the issue is still active:
-     `./scripts/edit-issue-labels.sh --issue ISSUE_NUMBER --remove-label "stale" --remove-label "autoclose"`
+     `./scripts/edit-issue-labels.sh --remove-label "stale" --remove-label "autoclose"`
    - If the issue has `needs-repro` or `needs-info` and the missing information has now been provided, remove the label:
-     `./scripts/edit-issue-labels.sh --issue ISSUE_NUMBER --remove-label "needs-repro"`
+     `./scripts/edit-issue-labels.sh --remove-label "needs-repro"`
    - If the issue doesn't have lifecycle labels but clearly needs them (e.g., a maintainer asked for repro steps or more details), add the appropriate label.
    - Comments like "+1", "me too", "same here", or emoji reactions are NOT the missing information. Only remove `needs-repro` or `needs-info` when substantive details are actually provided.
    - Do NOT add or remove category labels (bug, enhancement, etc.) on comment events.

.github/FEATURE_REQUEST_auto_mode_permission.md

@@ -0,0 +1,80 @@
+# Feature Request: Add "Enable auto-mode" to permission request options
+
+## Problem Statement
+
+When auto mode gets turned off (for various reasons like encountering a tool that requires explicit permission), users face an avalanche of back-to-back permission requests. This makes it very difficult to get the 2 seconds of uninterrupted time needed to navigate to settings and re-enable auto mode.
+
+Currently, users must either:
+1. Manually approve each permission request one-by-one, or
+2. Try to find a brief pause to navigate away and re-enable auto mode
+
+This creates a frustrating user experience, especially when multiple permission requests queue up rapidly.
+
+## Proposed Solution
+
+Add "Enable auto-mode" as a new option in permission request dialogs, alongside the existing options like:
+- Yes, allow
+- Yes, allow for this session  
+- Always allow
+- No, deny
+
+The new option would:
+1. Approve the current permission request
+2. Enable auto-mode for the remainder of the session
+3. Allow subsequent permission requests to be handled automatically by the auto-mode classifier
+
+### User Experience
+
+When a permission prompt appears, users would see something like:
+
+```
+Claude wants to run: npm test
+
+  > Yes, allow
+    Yes, allow for this session
+    Always allow
+    Enable auto-mode (approve this and future requests automatically)
+    No, deny
+```
+
+Selecting "Enable auto-mode" would:
+1. Immediately approve the current pending request
+2. Switch the session to auto-mode
+3. Continue processing any queued requests using auto-mode
+
+## Technical Context
+
+Based on CHANGELOG analysis, the relevant code areas include:
+- Permission prompt component (React/Ink-based UI)
+- `setPermissionMode` function for changing modes
+- Auto-mode classifier system
+- Session state management for permission modes
+
+The existing infrastructure supports:
+- `value:"allow_all"` for session-wide permissions
+- `value:"yes-accept-edits"` for auto-accepting edits
+- Mode transitions via keyboard shortcuts (Shift+Tab in plan mode)
+
+## Priority
+
+High - This is a significant impact on productivity, especially for users who rely on auto-mode for their workflow.
+
+## Feature Category
+
+Interactive mode (TUI)
+
+## Use Case Example
+
+1. User is working with auto-mode enabled
+2. A tool triggers that auto-mode can't classify (e.g., a sensitive operation)
+3. Auto-mode gets disabled, prompting for explicit permission
+4. User approves the operation
+5. Multiple follow-up tool calls also need permission
+6. Instead of approving each one, user selects "Enable auto-mode"
+7. Current request is approved and auto-mode handles the rest
+
+## Additional Context
+
+- Slack thread: https://anthropic.slack.com/archives/C07VBSHV7EV/p1774978648891819?thread_ts=1774978537.133329&cid=C07VBSHV7EV
+- Requested by Mark Christian
+- Related to improving the permission request UX when auto-mode is interrupted

.github/workflows/claude-dedupe-issues.yml

@@ -26,6 +26,7 @@ jobs:
         uses: anthropics/claude-code-action@v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          CLAUDE_CODE_SCRIPT_CAPS: '{"comment-on-duplicates.sh":1}'
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           allowed_non_write_users: "*"

.github/workflows/claude-issue-triage.yml

@@ -29,6 +29,7 @@ jobs:
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           GH_REPO: ${{ github.repository }}
+          CLAUDE_CODE_SCRIPT_CAPS: '{"edit-issue-labels.sh":2}'
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           allowed_non_write_users: "*"

scripts/comment-on-duplicates.sh

@@ -1,22 +1,28 @@
 #!/usr/bin/env bash
 #
 # Comments on a GitHub issue with a list of potential duplicates.
-# Usage: ./comment-on-duplicates.sh --base-issue 123 --potential-duplicates 456 789 101
+# Usage: ./comment-on-duplicates.sh --potential-duplicates 456 789 101
+#
+# The base issue number is read from the workflow event payload.
 #
 
 set -euo pipefail
 
 REPO="anthropics/claude-code"
-BASE_ISSUE=""
+
+# Read from event payload so the issue number is bound to the triggering event.
+# Falls back to workflow_dispatch inputs for manual runs.
+BASE_ISSUE=$(jq -r '.issue.number // .inputs.issue_number // empty' "${GITHUB_EVENT_PATH:?GITHUB_EVENT_PATH not set}")
+if ! [[ "$BASE_ISSUE" =~ ^[0-9]+$ ]]; then
+  echo "Error: no issue number in event payload" >&2
+  exit 1
+fi
+
 DUPLICATES=()
 
 # Parse arguments
 while [[ $# -gt 0 ]]; do
   case $1 in
-    --base-issue)
-      BASE_ISSUE="$2"
-      shift 2
-      ;;
     --potential-duplicates)
       shift
       while [[ $# -gt 0 && ! "$1" =~ ^-- ]]; do
@@ -25,23 +31,12 @@ while [[ $# -gt 0 ]]; do
       done
       ;;
     *)
-      echo "Unknown option: $1" >&2
+      echo "Error: unknown argument (only --potential-duplicates is accepted)" >&2
       exit 1
       ;;
   esac
 done
 
-# Validate base issue
-if [[ -z "$BASE_ISSUE" ]]; then
-  echo "Error: --base-issue is required" >&2
-  exit 1
-fi
-
-if ! [[ "$BASE_ISSUE" =~ ^[0-9]+$ ]]; then
-  echo "Error: --base-issue must be a number, got: $BASE_ISSUE" >&2
-  exit 1
-fi
-
 # Validate duplicates
 if [[ ${#DUPLICATES[@]} -eq 0 ]]; then
   echo "Error: --potential-duplicates requires at least one issue number" >&2

scripts/edit-issue-labels.sh

@@ -1,22 +1,27 @@
 #!/usr/bin/env bash
 #
 # Edits labels on a GitHub issue.
-# Usage: ./edit-issue-labels.sh --issue 123 --add-label bug --add-label needs-triage --remove-label untriaged
+# Usage: ./edit-issue-labels.sh --add-label bug --add-label needs-triage --remove-label untriaged
+#
+# The issue number is read from the workflow event payload.
 #
 
 set -euo pipefail
 
-ISSUE=""
+# Read from event payload so the issue number is bound to the triggering event.
+# Falls back to workflow_dispatch inputs for manual runs.
+ISSUE=$(jq -r '.issue.number // .inputs.issue_number // empty' "${GITHUB_EVENT_PATH:?GITHUB_EVENT_PATH not set}")
+if ! [[ "$ISSUE" =~ ^[0-9]+$ ]]; then
+  echo "Error: no issue number in event payload" >&2
+  exit 1
+fi
+
 ADD_LABELS=()
 REMOVE_LABELS=()
 
 # Parse arguments
 while [[ $# -gt 0 ]]; do
   case $1 in
-    --issue)
-      ISSUE="$2"
-      shift 2
-      ;;
     --add-label)
       ADD_LABELS+=("$2")
       shift 2
@@ -26,20 +31,12 @@ while [[ $# -gt 0 ]]; do
       shift 2
       ;;
     *)
+      echo "Error: unknown argument (only --add-label and --remove-label are accepted)" >&2
       exit 1
       ;;
   esac
 done
 
-# Validate issue number
-if [[ -z "$ISSUE" ]]; then
-  exit 1
-fi
-
-if ! [[ "$ISSUE" =~ ^[0-9]+$ ]]; then
-  exit 1
-fi
-
 if [[ ${#ADD_LABELS[@]} -eq 0 && ${#REMOVE_LABELS[@]} -eq 0 ]]; then
   exit 1
 fi