chore: Update CHANGELOG.md

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

.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

@@ -0,0 +1,70 @@
+---
+allowed-tools: Bash(./scripts/gh.sh:*),Bash(./scripts/edit-issue-labels.sh:*)
+description: Triage GitHub issues by analyzing and applying labels
+---
+
+You're an issue triage assistant. Analyze the issue and manage labels.
+
+IMPORTANT: Don't post any comments or messages to the issue. Your only actions are adding or removing labels.
+
+Context:
+
+$ARGUMENTS
+
+TOOLS:
+- `./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 `./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):**
+
+4. First, check if this issue is actually about Claude Code (the CLI/IDE tool). Issues about the Claude API, claude.ai, the Claude app, Anthropic billing, or other Anthropic products should be labeled `invalid`. If invalid, apply only that label and stop.
+
+5. Analyze and apply category labels:
+   - Type (bug, enhancement, question, etc.)
+   - Technical areas and platform
+   - 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.
+     Do NOT apply if the user already provided error messages, logs, file paths, or a description of what they did. Don't require a specific format — narrative descriptions count.
+     For model behavior issues (e.g. "Claude does X when it should do Y"), don't require traditional repro steps — examples and patterns are sufficient.
+   - `needs-info` (bugs only, 7 days): The issue needs something from the community before it can progress — e.g. error messages, versions, environment details, or answers to follow-up questions. Don't apply to questions or enhancements.
+     Do NOT apply if the user already provided version, environment, and error details. If the issue just needs engineering investigation, that's not `needs-info`.
+
+   Issues with these labels are automatically closed after the timeout if there's no response.
+   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"`
+
+**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"`
+   - 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"`
+   - 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.
+
+GUIDELINES:
+- 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
+- When in doubt, don't apply a lifecycle label — false positives are worse than missing labels
+- It's okay to not add any labels if none are clearly applicable

.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,78 +28,11 @@ 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: "*"
-          prompt: |
-            You're an issue triage assistant. Analyze the issue and manage labels.
-
-            IMPORTANT: Don't post any comments or messages to the issue. Your only actions are adding or removing labels.
-
-            Context:
-            - REPO: ${{ github.repository }}
-            - ISSUE_NUMBER: ${{ github.event.issue.number }}
-            - EVENT: ${{ github.event_name }}
-
-            ALLOWED LABELS — you may ONLY use labels from this list. Never invent new labels.
-
-            Type: bug, enhancement, question, documentation, duplicate, invalid
-            Lifecycle: needs-repro, needs-info, stale, autoclose
-            Platform: platform:linux, platform:macos, platform:windows, platform:wsl, platform:ios, platform:android, platform:vscode, platform:intellij, platform:web, platform:aws-bedrock
-            API: api:bedrock, api:vertex
-
-            TOOLS:
-            - `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
-            - `gh issue edit NUMBER --add-label` / `--remove-label`: Add or remove labels
-
-            TASK:
-
-            1. Run `gh issue view ${{ github.event.issue.number }}` to read the issue details.
-            2. Run `gh issue view ${{ github.event.issue.number }} --comments` to read the conversation.
-
-            **If EVENT is "issues" (new issue):**
-
-            3. First, check if this issue is actually about Claude Code (the CLI/IDE tool). Issues about the Claude API, claude.ai, the Claude app, Anthropic billing, or other Anthropic products should be labeled `invalid`. If invalid, apply only that label and stop.
-
-            4. 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.
-
-            5. 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.
-                 Do NOT apply if the user already provided error messages, logs, file paths, or a description of what they did. Don't require a specific format — narrative descriptions count.
-                 For model behavior issues (e.g. "Claude does X when it should do Y"), don't require traditional repro steps — examples and patterns are sufficient.
-               - `needs-info` (bugs only, 7 days): The issue needs something from the community before it can progress — e.g. error messages, versions, environment details, or answers to follow-up questions. Don't apply to questions or enhancements.
-                 Do NOT apply if the user already provided version, environment, and error details. If the issue just needs engineering investigation, that's not `needs-info`.
-
-               Issues with these labels are automatically closed after the timeout if there's no response.
-               The goal is to avoid issues lingering without a clear next step.
-
-            6. Apply all selected labels:
-               `gh issue edit ${{ github.event.issue.number }} --add-label "label1" --add-label "label2"`
-
-            **If EVENT is "issue_comment" (comment on existing issue):**
-
-            3. 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:
-                 `gh issue edit ${{ github.event.issue.number }} --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:
-                 `gh issue edit ${{ github.event.issue.number }} --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.
-
-            GUIDELINES:
-            - ONLY use labels from the ALLOWED LABELS list above — 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
-            - When in doubt, don't apply a lifecycle label — false positives are worse than missing labels
-            - It's okay to not add any labels if none are clearly applicable
+          prompt: "/triage-issue REPO: ${{ github.repository }} ISSUE_NUMBER: ${{ github.event.issue.number }} EVENT: ${{ github.event_name }}"
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           claude_args: |
             --model claude-opus-4-6
-            --allowedTools "Bash(gh issue view:*),Bash(gh issue edit:*),Bash(gh search issues:*)"

.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,7 +1,93 @@
 # Changelog
 
+## 2.1.59
+
+- Claude automatically saves useful context to auto-memory. Manage with /memory
+- Added `/copy` command to show an interactive picker when code blocks are present, allowing selection of individual code blocks or the full response.
+- Improved "always allow" prefix suggestions for compound bash commands (e.g. `cd /tmp && git fetch && git push`) to compute smarter per-subcommand prefixes instead of treating the whole command as one
+- Improved ordering of short task lists
+- Improved memory usage in multi-agent sessions by releasing completed subagent task state
+- Fixed MCP OAuth token refresh race condition when running multiple Claude Code instances simultaneously
+- Fixed shell commands not showing a clear error message when the working directory has been deleted
+
+## 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")
+
+## 2.1.51
+
+- Added `claude remote-control` subcommand for external builds, enabling local environment serving for all users.
+- Updated plugin marketplace default git timeout from 30s to 120s and added `CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS` to configure.
+- Added support for custom npm registries and specific version pinning when installing plugins from npm sources
+- BashTool now skips login shell (`-l` flag) by default when a shell snapshot is available, improving command execution performance. Previously this required setting `CLAUDE_BASH_NO_LOGIN=true`.
+- Fixed a security issue where `statusLine` and `fileSuggestion` hook commands could execute without workspace trust acceptance in interactive mode.
+- Tool results larger than 50K characters are now persisted to disk (previously 100K). This reduces context window usage and improves conversation longevity.
+- Fixed a bug where duplicate `control_response` messages (e.g. from WebSocket reconnects) could cause API 400 errors by pushing duplicate assistant messages into the conversation.
+- 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
+
+- Added support for `startupTimeout` configuration for LSP servers
+- Added `WorktreeCreate` and `WorktreeRemove` hook events, enabling custom VCS setup and teardown when agent worktree isolation creates or removes worktrees.
+- Fixed a bug where resumed sessions could be invisible when the working directory involved symlinks, because the session storage path was resolved at different times during startup. Also fixed session data loss on SSH disconnect by flushing session data before hooks and analytics in the graceful shutdown sequence.
+- Linux: Fixed native modules not loading on systems with glibc older than 2.30 (e.g., RHEL 8)
+- Fixed memory leak in agent teams where completed teammate tasks were never garbage collected from session state
+- Fixed `CLAUDE_CODE_SIMPLE` to fully strip down skills, session memory, custom agents, and CLAUDE.md token counting
+- Fixed `/mcp reconnect` freezing the CLI when given a server name that doesn't exist
+- Fixed memory leak where completed task state objects were never removed from AppState
+- Added support for `isolation: worktree` in agent definitions, allowing agents to declaratively run in isolated git worktrees.
+- `CLAUDE_CODE_SIMPLE` mode now also disables MCP tools, attachments, hooks, and CLAUDE.md file loading for a fully minimal experience.
+- Fixed bug where MCP tools were not discovered when tool search is enabled and a prompt is passed in as a launch argument
+- Improved memory usage during long sessions by clearing internal caches after compaction
+- Added `claude agents` CLI command to list all configured agents
+- Improved memory usage during long sessions by clearing large tool results after they have been processed
+- Fixed a memory leak where LSP diagnostic data was never cleaned up after delivery, causing unbounded memory growth in long sessions
+- Fixed a memory leak where completed task output was not freed from memory, reducing memory usage in long sessions with many tasks
+- Improved startup performance for headless mode (`-p` flag) by deferring Yoga WASM and UI component imports
+- Fixed prompt suggestion cache regression that reduced cache hit rates
+- Fixed unbounded memory growth in long sessions by capping file history snapshots
+- Added `CLAUDE_CODE_DISABLE_1M_CONTEXT` environment variable to disable 1M context window support
+- Opus 4.6 (fast mode) now includes the full 1M context window
+- VSCode: Added `/extra-usage` command support in VS Code sessions
+- Fixed memory leak where TaskOutput retained recent lines after cleanup
+- Fixed memory leak in CircularBuffer where cleared items were retained in the backing array
+- Fixed memory leak in shell command execution where ChildProcess and AbortController references were retained after cleanup
+
 ## 2.1.49
 
+- Improved MCP OAuth authentication with step-up auth support and discovery caching, reducing redundant network requests during server connections
+- Added `--worktree` (`-w`) flag to start Claude in an isolated git worktree
+- Subagents support `isolation: "worktree"` for working in a temporary git worktree
+- Added Ctrl+F keybinding to kill background agents (two-press confirmation)
+- Agent definitions support `background: true` to always run as a background task
+- Plugins can ship `settings.json` for default configuration
+- Fixed file-not-found errors to suggest corrected paths when the model drops the repo folder
 - Fixed Ctrl+C and ESC being silently ignored when background agents are running and the main thread is idle. Pressing twice within 3 seconds now kills all background agents.
 - Fixed prompt suggestion cache regression that reduced cache hit rates.
 - Fixed `plugin enable` and `plugin disable` to auto-detect the correct scope when `--scope` is not specified, instead of always defaulting to user scope

scripts/edit-issue-labels.sh

@@ -0,0 +1,87 @@
+#!/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
+#
+
+set -euo pipefail
+
+ISSUE=""
+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
+      ;;
+    --remove-label)
+      REMOVE_LABELS+=("$2")
+      shift 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
+
+# Fetch valid labels from the repo
+VALID_LABELS=$(gh label list --limit 500 --json name --jq '.[].name')
+
+# Filter to only labels that exist in the repo
+FILTERED_ADD=()
+for label in "${ADD_LABELS[@]}"; do
+  if echo "$VALID_LABELS" | grep -qxF "$label"; then
+    FILTERED_ADD+=("$label")
+  fi
+done
+
+FILTERED_REMOVE=()
+for label in "${REMOVE_LABELS[@]}"; do
+  if echo "$VALID_LABELS" | grep -qxF "$label"; then
+    FILTERED_REMOVE+=("$label")
+  fi
+done
+
+if [[ ${#FILTERED_ADD[@]} -eq 0 && ${#FILTERED_REMOVE[@]} -eq 0 ]]; then
+  exit 0
+fi
+
+# Build gh command arguments
+GH_ARGS=("issue" "edit" "$ISSUE")
+
+for label in "${FILTERED_ADD[@]}"; do
+  GH_ARGS+=("--add-label" "$label")
+done
+
+for label in "${FILTERED_REMOVE[@]}"; do
+  GH_ARGS+=("--remove-label" "$label")
+done
+
+gh "${GH_ARGS[@]}"
+
+if [[ ${#FILTERED_ADD[@]} -gt 0 ]]; then
+  echo "Added: ${FILTERED_ADD[*]}"
+fi
+if [[ ${#FILTERED_REMOVE[@]} -gt 0 ]]; then
+  echo "Removed: ${FILTERED_REMOVE[*]}"
+fi

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