Remove unused id-token permission and migrate oncall-triage to gh.sh wrapper

Add gh.sh wrapper for gh CLI commands in triage and dedupe workflows

.claude/commands/dedupe.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(./scripts/comment-on-duplicates.sh:*)
+allowed-tools: Bash(./scripts/gh.sh:*), Bash(./scripts/comment-on-duplicates.sh:*)
 description: Find duplicate GitHub issues
 ---
 
@@ -18,6 +18,10 @@ To do this, follow these steps precisely:
 
 Notes (be sure to tell this to your agents, too):
 
-- Use `gh` to interact with Github, rather than web fetch
-- Do not use other tools, beyond `gh` and the comment script (eg. don't use other MCP servers, file edit, etc.)
+- Use `./scripts/gh.sh` to interact with Github, rather than web fetch or raw `gh`. Examples:
+  - `./scripts/gh.sh issue view 123` — view an issue
+  - `./scripts/gh.sh issue view 123 --comments` — view with comments
+  - `./scripts/gh.sh issue list --state open --limit 20` — list issues
+  - `./scripts/gh.sh search issues "query" --limit 10` — search for issues
+- Do not use other tools, beyond `./scripts/gh.sh` and the comment script (eg. don't use other MCP servers, file edit, etc.)
 - Make a todo list first

.claude/commands/oncall-triage-ci.md

@@ -0,0 +1,66 @@
+---
+allowed-tools: Bash(./scripts/gh.sh:*), Bash(./scripts/edit-issue-labels.sh:*), TodoWrite
+description: Triage GitHub issues for oncall attention (CI workflow version)
+---
+
+You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
+
+Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
+
+$ARGUMENTS
+
+TOOLS:
+- `./scripts/gh.sh` — wrapper for `gh` CLI. Example commands:
+  - `./scripts/gh.sh issue list --state open --label bug --limit 100` — list open bugs
+  - `./scripts/gh.sh issue view 123` — view issue details
+  - `./scripts/gh.sh issue view 123 --comments` — view with comments
+  - `./scripts/gh.sh search issues "query" --limit 10` — search for issues
+- `./scripts/edit-issue-labels.sh --issue NUMBER --add-label LABEL` — add labels to an issue
+
+Task overview:
+
+1. Fetch all open issues updated in the last 3 days:
+   - Use `./scripts/gh.sh issue list --state open --limit 100` to get issues
+   - This will give you the most recently updated issues first
+   - For each page of results, check the updatedAt timestamp of each issue
+   - Add issues updated within the last 3 days (72 hours) to your TODO list as you go
+   - Once you hit issues older than 3 days, you can stop fetching
+
+2. Build your TODO list incrementally as you fetch:
+   - As you fetch each page, immediately add qualifying issues to your TODO list
+   - One TODO item per issue number (e.g., "Evaluate issue #123")
+   - This allows you to start processing while still fetching more pages
+
+3. For each issue in your TODO list:
+   - Use `./scripts/gh.sh issue view <number>` to read the issue details (title, body, labels)
+   - Use `./scripts/gh.sh issue view <number> --comments` to read all comments
+   - Evaluate whether this issue needs the oncall label:
+     a) Is it a bug? (has "bug" label or describes bug behavior)
+     b) Does it have at least 50 engagements? (count comments + reactions)
+     c) Is it truly blocking? Read and understand the full content to determine:
+        - Does this prevent core functionality from working?
+        - Can users work around it?
+        - Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
+        - Be conservative - only flag issues that truly prevent users from getting work done
+
+4. For issues that meet all criteria and do not already have the "oncall" label:
+   - Use `./scripts/edit-issue-labels.sh --issue <number> --add-label "oncall"`
+   - Do not post any comments
+   - Do not remove any existing labels
+   - Do not remove the "oncall" label from issues that already have it
+
+Important guidelines:
+- Use the TODO list to track your progress through ALL candidate issues
+- Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
+- Be conservative in your assessment - only flag truly critical blocking issues
+- Do not post any comments to issues
+- Your only action should be to add the "oncall" label using ./scripts/edit-issue-labels.sh
+- Mark each issue as complete in your TODO list as you process it
+
+5. After processing all issues in your TODO list, provide a summary of your actions:
+   - Total number of issues processed (candidate issues evaluated)
+   - Number of issues that received the "oncall" label
+   - For each issue that got the label: list issue number, title, and brief reason why it qualified
+   - Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
+   - If no issues qualified, state that clearly
+   - Format the summary clearly for easy reading

.claude/commands/triage-issue.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Bash(gh label list:*),Bash(gh issue view:*),Bash(./scripts/edit-issue-labels.sh:*),Bash(gh search issues:*)
+allowed-tools: Bash(./scripts/gh.sh:*),Bash(./scripts/edit-issue-labels.sh:*)
 description: Triage GitHub issues by analyzing and applying labels
 ---
 
@@ -12,17 +12,21 @@ Context:
 $ARGUMENTS
 
 TOOLS:
-- `gh label list`: Fetch all available labels in this repo
-- `gh issue view NUMBER`: Read the issue title, body, and labels
-- `gh issue view NUMBER --comments`: Read the conversation
-- `gh search issues QUERY`: Find similar or duplicate issues
-- `./scripts/edit-issue-labels.sh --issue NUMBER --add-label LABEL --remove-label LABEL`: Add or remove labels
+- `./scripts/gh.sh` — wrapper for `gh` CLI. Only supports these subcommands and flags:
+  - `./scripts/gh.sh label list` — fetch all available labels
+  - `./scripts/gh.sh label list --limit 100` — fetch with limit
+  - `./scripts/gh.sh issue view 123` — read issue title, body, and labels
+  - `./scripts/gh.sh issue view 123 --comments` — read the conversation
+  - `./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
 
 TASK:
 
-1. Run `gh label list` to fetch the available labels. You may ONLY use labels from this list. Never invent new labels.
-2. Run `gh issue view ISSUE_NUMBER` to read the issue details.
-3. Run `gh issue view ISSUE_NUMBER --comments` to read the conversation.
+1. Run `./scripts/gh.sh label list` to fetch the available labels. You may ONLY use labels from this list. Never invent new labels.
+2. Run `./scripts/gh.sh issue view ISSUE_NUMBER` to read the issue details.
+3. Run `./scripts/gh.sh issue view ISSUE_NUMBER --comments` to read the conversation.
 
 **If EVENT is "issues" (new issue):**
 
@@ -31,7 +35,7 @@ TASK:
 5. Analyze and apply category labels:
    - Type (bug, enhancement, question, etc.)
    - Technical areas and platform
-   - Check for duplicates with `gh search issues`. Only mark as duplicate of OPEN issues.
+   - Check for duplicates with `./scripts/gh.sh search issues`. Only mark as duplicate of OPEN issues.
 
 6. Evaluate lifecycle labels:
    - `needs-repro` (bugs only, 7 days): Bug reports without clear steps to reproduce. A good repro has specific, followable steps that someone else could use to see the same issue.
@@ -58,7 +62,7 @@ TASK:
    - Do NOT add or remove category labels (bug, enhancement, etc.) on comment events.
 
 GUIDELINES:
-- ONLY use labels from `gh label list` — never create or guess label names
+- ONLY use labels from `./scripts/gh.sh label list` — never create or guess label names
 - DO NOT post any comments to the issue
 - Be conservative with lifecycle labels — only apply when clearly warranted
 - Only apply lifecycle labels (`needs-repro`, `needs-info`) to bugs — never to questions or enhancements

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

@@ -17,7 +17,6 @@ jobs:
     permissions:
       contents: read
       issues: write
-      id-token: write
 
     steps:
       - name: Checkout repository

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

@@ -18,7 +18,6 @@ jobs:
     permissions:
       contents: read
       issues: write
-      id-token: write
 
     steps:
       - name: Checkout repository
@@ -29,6 +28,7 @@ jobs:
         uses: anthropics/claude-code-action@v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GH_REPO: ${{ github.repository }}
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           allowed_non_write_users: "*"

.github/workflows/non-write-users-check.yml

@@ -0,0 +1,47 @@
+name: Non-write Users Check
+on:
+  pull_request:
+    paths:
+      - ".github/**"
+
+permissions:
+  contents: read
+  pull-requests: write
+
+jobs:
+  allowed-non-write-check:
+    runs-on: ubuntu-latest
+    env:
+      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+    steps:
+      - run: |
+          DIFF=$(gh pr diff "$PR_NUMBER" -R "$REPO" || true)
+
+          if ! echo "$DIFF" | grep -qE '^diff --git a/\.github/.*\.ya?ml'; then
+            exit 0
+          fi
+
+          MATCHES=$(echo "$DIFF" | grep "^+.*allowed_non_write_users" || true)
+
+          if [ -z "$MATCHES" ]; then
+            exit 0
+          fi
+
+          EXISTING=$(gh pr view "$PR_NUMBER" -R "$REPO" --json comments --jq '.comments[].body' \
+            | grep -c "<!-- non-write-users-check -->" || true)
+
+          if [ "$EXISTING" -gt 0 ]; then
+            exit 0
+          fi
+
+          gh pr comment "$PR_NUMBER" -R "$REPO" --body '<!-- non-write-users-check -->
+          **`allowed_non_write_users` detected**
+
+          This PR adds or modifies `allowed_non_write_users`, which allows users without write access to trigger Claude Code Action workflows. This can introduce security risks.
+
+          If this is a new flow, please make sure you actually need `allowed_non_write_users`. If you are editing an existing workflow, double check that you are not adding new Claude permissions which might lead to a vulnerability.
+
+          See existing workflows in this repo for safe usage examples, or contact the AppSec team.'
+        env:
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+          REPO: ${{ github.repository }}

.github/workflows/oncall-triage.yml

@@ -16,103 +16,19 @@ jobs:
     permissions:
       contents: read
       issues: write
-      id-token: write
 
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      - name: Setup GitHub MCP Server
-        run: |
-          mkdir -p /tmp/mcp-config
-          cat > /tmp/mcp-config/mcp-servers.json << 'EOF'
-          {
-            "mcpServers": {
-              "github": {
-                "command": "docker",
-                "args": [
-                  "run",
-                  "-i",
-                  "--rm",
-                  "-e",
-                  "GITHUB_PERSONAL_ACCESS_TOKEN",
-                  "ghcr.io/github/github-mcp-server:sha-7aced2b"
-                ],
-                "env": {
-                  "GITHUB_PERSONAL_ACCESS_TOKEN": "${{ secrets.GITHUB_TOKEN }}"
-                }
-              }
-            }
-          }
-          EOF
-
       - name: Run Claude Code for Oncall Triage
         timeout-minutes: 10
         uses: anthropics/claude-code-action@v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GH_REPO: ${{ github.repository }}
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           allowed_non_write_users: "*"
-          prompt: |
-            You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
-
-            Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
-
-            Repository: ${{ github.repository }}
-
-            Task overview:
-            1. Fetch all open issues updated in the last 3 days:
-               - Use mcp__github__list_issues with:
-                 - state="open"
-                 - first=5 (fetch only 5 issues per page)
-                 - orderBy="UPDATED_AT"
-                 - direction="DESC"
-               - This will give you the most recently updated issues first
-               - For each page of results, check the updatedAt timestamp of each issue
-               - Add issues updated within the last 3 days (72 hours) to your TODO list as you go
-               - Keep paginating using the 'after' parameter until you encounter issues older than 3 days
-               - Once you hit issues older than 3 days, you can stop fetching (no need to fetch all open issues)
-
-            2. Build your TODO list incrementally as you fetch:
-               - As you fetch each page, immediately add qualifying issues to your TODO list
-               - One TODO item per issue number (e.g., "Evaluate issue #123")
-               - This allows you to start processing while still fetching more pages
-
-            3. For each issue in your TODO list:
-               - Use mcp__github__get_issue to read the issue details (title, body, labels)
-               - Use mcp__github__get_issue_comments to read all comments
-               - Evaluate whether this issue needs the oncall label:
-                 a) Is it a bug? (has "bug" label or describes bug behavior)
-                 b) Does it have at least 50 engagements? (count comments + reactions)
-                 c) Is it truly blocking? Read and understand the full content to determine:
-                    - Does this prevent core functionality from working?
-                    - Can users work around it?
-                    - Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
-                    - Be conservative - only flag issues that truly prevent users from getting work done
-
-            4. For issues that meet all criteria and do not already have the "oncall" label:
-               - Use mcp__github__update_issue to add the "oncall" label
-               - Do not post any comments
-               - Do not remove any existing labels
-               - Do not remove the "oncall" label from issues that already have it
-
-            Important guidelines:
-            - Use the TODO list to track your progress through ALL candidate issues
-            - Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
-            - Be conservative in your assessment - only flag truly critical blocking issues
-            - Do not post any comments to issues
-            - Your only action should be to add the "oncall" label using mcp__github__update_issue
-            - Mark each issue as complete in your TODO list as you process it
-
-            7. After processing all issues in your TODO list, provide a summary of your actions:
-               - Total number of issues processed (candidate issues evaluated)
-               - Number of issues that received the "oncall" label
-               - For each issue that got the label: list issue number, title, and brief reason why it qualified
-               - Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
-               - If no issues qualified, state that clearly
-               - Format the summary clearly for easy reading
+          prompt: "/oncall-triage-ci REPO: ${{ github.repository }}"
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
-          claude_args: |
-            --mcp-config /tmp/mcp-config/mcp-servers.json
-            --allowedTools "mcp__github__list_issues,mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue"

CHANGELOG.md

@@ -1,5 +1,28 @@
 # Changelog
 
+## 2.1.58
+
+- Expand Remote Control to more users
+
+## 2.1.56
+
+- VS Code: Fixed another cause of "command 'claude-vscode.editor.openLast' not found" crashes
+
+## 2.1.55
+
+- Fixed BashTool failing on Windows with EINVAL error
+
+## 2.1.53
+
+- Fixed a UI flicker where user input would briefly disappear after submission before the message rendered
+- Fixed bulk agent kill (ctrl+f) to send a single aggregate notification instead of one per agent, and to properly clear the command queue
+- Fixed graceful shutdown sometimes leaving stale sessions when using Remote Control by parallelizing teardown network calls
+- Fixed `--worktree` sometimes being ignored on first launch
+- Fixed a panic ("switch on corrupted value") on Windows
+- Fixed a crash that could occur when spawning many processes on Windows
+- Fixed a crash in the WebAssembly interpreter on Linux x64 & Windows x64
+- Fixed a crash that sometimes occurred after 2 minutes on Windows ARM64
+
 ## 2.1.52
 
 - VS Code: Fixed extension crash on Windows ("command 'claude-vscode.editor.openLast' not found")
@@ -16,6 +39,7 @@
 - Added `CLAUDE_CODE_ACCOUNT_UUID`, `CLAUDE_CODE_USER_EMAIL`, and `CLAUDE_CODE_ORGANIZATION_UUID` environment variables for SDK callers to provide account info synchronously, eliminating a race condition where early telemetry events lacked account metadata.
 - Fixed slash command autocomplete crashing when a plugin's SKILL.md description is a YAML array or other non-string type
 - The `/model` picker now shows human-readable labels (e.g., "Sonnet 4.5") instead of raw model IDs for pinned model versions, with an upgrade hint when a newer version is available.
+- Managed settings can now be set via macOS plist or Windows Registry. Learn more at https://code.claude.com/docs/en/settings#settings-files
 
 ## 2.1.50
 

scripts/gh.sh

@@ -0,0 +1,85 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Wrapper around gh CLI that only allows specific subcommands and flags.
+# All commands are scoped to the current repository via GH_REPO or GITHUB_REPOSITORY.
+#
+# Usage:
+#   ./scripts/gh.sh issue view 123
+#   ./scripts/gh.sh issue view 123 --comments
+#   ./scripts/gh.sh issue list --state open --limit 20
+#   ./scripts/gh.sh search issues "search query" --limit 10
+#   ./scripts/gh.sh label list --limit 100
+
+ALLOWED_FLAGS=(--comments --state --limit --label)
+FLAGS_WITH_VALUES=(--state --limit --label)
+
+SUB1="${1:-}"
+SUB2="${2:-}"
+CMD="$SUB1 $SUB2"
+case "$CMD" in
+  "issue view"|"issue list"|"search issues"|"label list")
+    ;;
+  *)
+    exit 1
+    ;;
+esac
+
+shift 2
+
+# Separate flags from positional arguments
+POSITIONAL=()
+FLAGS=()
+skip_next=false
+for arg in "$@"; do
+  if [[ "$skip_next" == true ]]; then
+    FLAGS+=("$arg")
+    skip_next=false
+  elif [[ "$arg" == -* ]]; then
+    flag="${arg%%=*}"
+    matched=false
+    for allowed in "${ALLOWED_FLAGS[@]}"; do
+      if [[ "$flag" == "$allowed" ]]; then
+        matched=true
+        break
+      fi
+    done
+    if [[ "$matched" == false ]]; then
+      exit 1
+    fi
+    FLAGS+=("$arg")
+    # If flag expects a value and isn't using = syntax, skip next arg
+    if [[ "$arg" != *=* ]]; then
+      for vflag in "${FLAGS_WITH_VALUES[@]}"; do
+        if [[ "$flag" == "$vflag" ]]; then
+          skip_next=true
+          break
+        fi
+      done
+    fi
+  else
+    POSITIONAL+=("$arg")
+  fi
+done
+
+REPO="${GH_REPO:-${GITHUB_REPOSITORY:-}}"
+
+if [[ "$CMD" == "search issues" ]]; then
+  if [[ -z "$REPO" ]]; then
+    exit 1
+  fi
+  QUERY="${POSITIONAL[0]:-}"
+  QUERY_LOWER=$(echo "$QUERY" | tr '[:upper:]' '[:lower:]')
+  if [[ "$QUERY_LOWER" == *"repo:"* || "$QUERY_LOWER" == *"org:"* || "$QUERY_LOWER" == *"user:"* ]]; then
+    exit 1
+  fi
+  gh "$SUB1" "$SUB2" "$QUERY" --repo "$REPO" "${FLAGS[@]}"
+else
+  # Reject URLs in positional args to prevent cross-repo access
+  for pos in "${POSITIONAL[@]}"; do
+    if [[ "$pos" == http://* || "$pos" == https://* ]]; then
+      exit 1
+    fi
+  done
+  gh "$SUB1" "$SUB2" "${POSITIONAL[@]}" "${FLAGS[@]}"
+fi