{ "schemaVersion": 3, "dataset": { "version": 3, "date": "2026-08-13", "group": { "id": "coding-agent-infrastructure", "name": "Coding-Agent Infrastructure" }, "repository": { "id": "claude-code", "repo": "anthropics/claude-code", "name": "Claude Code", "keywords": [ "Claude Code" ] }, "context": { "repository": "anthropics/claude-code", "url": "https://github.com/anthropics/claude-code", "description": "Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.", "homepage": "https://code.claude.com/docs/en/overview", "language": "Python", "topics": [], "defaultBranch": "main", "stars": 141341, "forks": 22697, "openIssues": 16027, "archived": false, "collectedAt": "2026-08-13T18:02:14.001087+00:00" }, "news": { "repository": "anthropics/claude-code", "collectedAt": "2026-08-13T18:02:14.001087+00:00", "latestRelease": { "repository": "anthropics/claude-code", "tag": "v2.1.231", "title": "v2.1.231", "url": "https://github.com/anthropics/claude-code/releases/tag/v2.1.231", "publishedAt": "2026-08-13T08:38:50Z", "notes": "## What's changed\n\n- Fixed MCP OAuth sign-in failing with a redirect URI mismatch for servers that use a pre-registered OAuth client, such as Slack\n", "highlights": [ "What's changed", "Fixed MCP OAuth sign-in failing with a redirect URI mismatch for servers that use a pre-registered OAuth client, such as Slack" ], "prerelease": false }, "upcoming": [ { "repository": "anthropics/claude-code", "kind": "milestone", "title": "P1", "url": "https://github.com/anthropics/claude-code/milestone/1", "description": "", "progress": 100, "openIssues": 0, "closedIssues": 14 }, { "repository": "anthropics/claude-code", "kind": "milestone", "title": "P2", "url": "https://github.com/anthropics/claude-code/milestone/2", "description": "", "progress": 100, "openIssues": 0, "closedIssues": 15 }, { "repository": "anthropics/claude-code", "kind": "milestone", "title": "P3", "url": "https://github.com/anthropics/claude-code/milestone/3", "description": "", "progress": 90, "openIssues": 1, "closedIssues": 9 } ], "communityDiscussions": [] }, "runs": [ { "collectedAt": "2026-08-13T12:26:38.318Z", "since": "2026-08-12T12:26:38.318Z", "observedCount": 502, "changedCount": 502 }, { "collectedAt": "2026-08-13T13:48:00.446149Z", "since": "2026-08-12T13:48:00.446149Z", "observedCount": 502, "changedCount": 502 }, { "collectedAt": "2026-08-13T16:19:22.035158Z", "since": "2026-08-12T16:19:22.035158Z", "observedCount": 502, "changedCount": 379 }, { "collectedAt": "2026-08-13T17:43:20.785491Z", "since": "2026-08-12T17:43:20.785491Z", "observedCount": 502, "changedCount": 60 }, { "collectedAt": "2026-08-13T17:47:07.884300Z", "since": "2026-08-12T17:47:07.884300Z", "observedCount": 502, "changedCount": 7 }, { "collectedAt": "2026-08-13T18:01:55.420671Z", "since": "2026-08-12T18:01:55.420671Z", "observedCount": 502, "changedCount": 11 } ], "signals": [ { "id": "github:anthropics/claude-code:issue:11592", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Anthropic API Error: Internal Server Error (500)", "text": "**Bug Description** 500 error **Environment Info** - Platform: darwin - Terminal: Apple_Terminal - Version: 2.0.37 - Feedback ID: 35e932b8-1b3a-45ca-8e44-142b76601f43 **Errors** ```json [{\"error\":\"Error: 500 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"api_error\\\",\\\"message\\\":\\\"Internal server error\\\"},\\\"request_id\\\":null}\\n at $4.generate (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:231:83308)\\n at q_.makeStatusError (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:716:2117)\\n at q_.makeRequest (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:716:5341)\\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\\n at async Qs2.xnA.model (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:15306)\\n at async xnA (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:1833:39781)\\n at async Qs2 (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:15460)\\n at async file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:8933\\n at async w00 (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:1970)\\n at async S8A (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:8903)\",\"timestamp\":\"2025-11-14T00:11:18.347Z\"},{\"error\":\"Error: 500 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"api_error\\\",\\\"message\\\":\\\"Internal server error\\\"},\\\"request_id\\\":null}\\n at $4.generate (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:231:83308)\\n at q_.makeStatusError (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:716:2117)\\n at q_.makeRequest (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:716:5341)\\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\\n at async Qs2.xnA.model (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:15306)\\n at async xnA (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:1833:39781)\\n at async Qs2 (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:15460)\\n at async file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:8933\\n at async w00 (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:1970)\\n at async S8A (file:///Users/ryanbrock/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:3534:8903)\",\"timestamp\":\"2025-11-14T00:11:41.880Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/11592", "createdAt": "2025-11-14T00:13:51Z", "updatedAt": "2026-08-13T14:28:58Z", "timestamp": "2026-08-13T14:28:58Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "stale" ], "author": "pillar-and-co", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:12026", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Auto-update fails repeatedly with ENOTEMPTY error on macOS with nvm", "text": "## Environment - **OS**: macOS (Darwin 24.6.0) - **Node Version**: v22.10.0 - **npm Version**: 10.9.0 - **Node Manager**: nvm - **Claude Code Version**: 2.0.46 โ†’ 2.0.47 (failing to update) - **Installation Path**: `~/.nvm/versions/node/v22.10.0/lib/node_modules/@anthropic-ai/claude-code` ## Description Claude Code's auto-update mechanism repeatedly fails with an `ENOTEMPTY` error when attempting to update from version 2.0.46 to 2.0.47. Each failed update leaves behind a stale temporary directory (`.claude-code-euxhxob3`), which prevents all subsequent auto-update attempts from succeeding. This results in the constant error message: **\"auto-update failed * try claude doctor\"** ## Error Message ``` npm error code ENOTEMPTY npm error syscall rename npm error path /Users/[username]/.nvm/versions/node/v22.10.0/lib/node_modules/@anthropic-ai/claude-code npm error dest /Users/[username]/.nvm/versions/node/v22.10.0/lib/node_modules/@anthropic-ai/.claude-code-euxhxob3 npm error errno -66 npm error ENOTEMPTY: directory not empty, rename '.../@anthropic-ai/claude-code' -> '.../@anthropic-ai/.claude-code-euxhxob3' ``` ## Reproduction Steps 1. Install Claude Code via npm on macOS with nvm 2. Launch Claude Code (which triggers auto-update check) 3. When a new version is available, the auto-updater attempts to update in the background 4. The update fails, leaving a `.claude-code-*` temp directory 5. All subsequent auto-update attempts fail with ENOTEMPTY error 6. User sees \"auto-update failed * try claude doctor\" message constantly ## Root Cause Analysis 1. npm's atomic update strategy tries to rename the existing installation to a temp directory 2. The temp directory name appears to be static/deterministic (`.claude-code-euxhxob3`) 3. When the first update fails, the temp directory persists 4. Subsequent attempts try to use the same temp directory name, resulting in ENOTEMPTY 5. Contributing factors: - macOS extended attributes (`com.apple.provenance`) on the installation - Large installation size (90MB) - Possible file handles from running Claude Code process - npm's atomic rename operation failing mid-transaction ## Workaround ```bash # Remove stale temp directory rm -rf ~/.nvm/versions/node/*/lib/node_modules/@anthropic-ai/.claude-code-* # Update manually npm update -g @anthropic-ai/claude-code # Or disable auto-updates export DISABLE_AUTOUPDATER=1 ``` ## Suggested Fixes 1. **Use unique temp directory names** (timestamp-based) instead of static names 2. **Clean up stale temp directories** before attempting update 3. **Add error handling** to retry with a different temp directory name if ENOTEMPTY occurs 4. **Gracefully degrade** by notifying user and suggesting manual update instead of repeatedly failing silently 5. **Check for running processes** before attempting update ## Impact - User constantly sees \"auto-update failed\" error messages - Auto-update mechanism becomes permanently broken until manual intervention - Likely affects nvm users on macOS (and possibly other Node version managers)", "url": "https://github.com/anthropics/claude-code/issues/12026", "createdAt": "2025-11-20T13:45:44Z", "updatedAt": "2026-08-13T07:23:25Z", "timestamp": "2026-08-13T07:23:25Z", "metrics": { "reactions": 7, "comments": 5 }, "labels": [ "bug", "duplicate", "has repro", "platform:macos", "area:packaging" ], "author": "david-gethers-cityblock", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:13498", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Installation failed Failed to fetch version from stable: AxiosError: timeout of 30000ms exceeded", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The native installer fails with timeout errors on Ubuntu 22.04, despite curl successfully reaching all required endpoints. The installer times out at two different stages: 1. Initial version fetch - 30-second timeout fetching from https://storage.googleapis.com/.../stable 2. Binary download - 10-second timeout downloading from https://downloads.claude.ai/claude-code-releases/2.0.61/linux-x64/claude Both endpoints respond successfully to curl commands with 200 OK responses. The same installer works successfully on Ubuntu 24.04. ### What Should Happen? Installer should successfully download and install Claude Code, as it does on Ubuntu 24.04. ### Error Messages/Logs ```shell Key error from logs: 2025-12-09T19:02:39.044Z [ERROR] Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/stable: timeout of 30000ms exceeded 2025-12-09T19:02:39.045Z [ERROR] Install command failed: Error: Failed to fetch version from stable: AxiosError: timeout of 30000ms exceeded Network connectivity verified - all succeed with 200 OK: curl -I https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/stable curl -I https://downloads.claude.ai/claude-code-releases/2.0.61/manifest.json curl -I https://downloads.claude.ai/claude-code-releases/2.0.61/linux-x64/claude ``` ### Steps to Reproduce 1. On Ubuntu 22.04, run: curl -fsSL https://claude.ai/install.sh | bash 2. Installer times out fetching version from stable channel 3. Retry with specific version: curl -fsSL https://claude.ai/install.sh | bash -s 2.0.61 4. Installer times out downloading the binary (~100MB file) ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.0.61 ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell Other ### Additional Information OS: Ubuntu 22.04 LTS Installation method: Native installer (curl -fsSL https://claude.ai/install.sh | bash) Claude Code version: Attempting to install 2.0.61 (stable) Works on: Ubuntu 24.04 with same installer", "url": "https://github.com/anthropics/claude-code/issues/13498", "createdAt": "2025-12-09T19:31:00Z", "updatedAt": "2026-08-13T03:25:08Z", "timestamp": "2026-08-13T03:25:08Z", "metrics": { "reactions": 14, "comments": 13 }, "labels": [ "bug", "has repro", "platform:linux", "area:packaging" ], "author": "eblack-leaf", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:14061", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] /plugin update does not invalidate plugin cache", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When running `/plugin update`, the marketplace git repository is updated correctly, but the plugin cache in `~/.claude/plugins/cache/` is not cleared or updated. The `installed_plugins.json` file also retains the old `gitCommitSha`. This means updated plugin files are not reflected until the cache is manually deleted. ### What Should Happen? Plugin cache should be invalidated or updated when `/plugin update` is run, so that changes in the marketplace are reflected immediately. ### Error Messages/Logs ```shell No error messages - the command reports success but cache remains stale. Evidence: - ~/.claude/plugins/marketplaces/ - Updated (git pull works) โœ“ - ~/.claude/plugins/cache/ - Not updated (old files remain) โœ— - ~/.claude/plugins/installed_plugins.json - gitCommitSha not updated โœ— ``` ### Steps to Reproduce 1. Add a private marketplace hosted on GitLab: `/plugin marketplace add git@gitlab.com:your-org/your-marketplace.git` 2. Install a plugin from the marketplace: `/plugin install your-plugin@your-marketplace` 3. Make changes to the plugin in the marketplace repository (e.g., update commands or agents) 4. Run `/plugin update` 5. Check cache directory - files remain outdated: ```bash ls -la ~/.claude/plugins/cache/ 6. Compare with marketplace directory - this is updated: cd ~/.claude/plugins/marketplaces/your-marketplace && git log -1 Workaround: Manually delete cache directory: rm -rf ~/.claude/plugins/cache/ ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.0.69 (Claude Code) ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell Windows Terminal ### Additional Information Reporter: Claude Code 2.0.69 ๐Ÿค–", "url": "https://github.com/anthropics/claude-code/issues/14061", "createdAt": "2025-12-15T16:25:44Z", "updatedAt": "2026-08-12T23:44:06Z", "timestamp": "2026-08-12T23:44:06Z", "metrics": { "reactions": 32, "comments": 25 }, "labels": [ "bug", "duplicate", "has repro", "platform:linux", "area:core" ], "author": "shohei-sawaguchi", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:14920", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature Request] Add ability to disable individual Claude plugin skills", "text": "**Bug Description** I want to be able to disable claude plugin skills individually - for example, I don't find commit-commands:commit-push-pr or commit-commands:clean_gone useful, I just want :commit **Environment Info** - Platform: darwin - Terminal: iTerm.app - Version: 2.0.75 - Feedback ID: b9c26774-de01-49c2-98ff-767d9bcb65bf", "url": "https://github.com/anthropics/claude-code/issues/14920", "createdAt": "2025-12-20T23:32:50Z", "updatedAt": "2026-08-13T08:25:14Z", "timestamp": "2026-08-13T08:25:14Z", "metrics": { "reactions": 86, "comments": 15 }, "labels": [ "enhancement", "platform:macos", "area:core" ], "author": "petergeneric", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:16128", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] AWS Bedrock authentication support for Chrome extension", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Our organization uses AWS Bedrock for Claude access. The CLI supports this via CLAUDE_CODE_USE_BEDROCK=1, but the Chrome extension only supports Claude.ai account login. Users with Bedrock-only access cannot use the extension at all, creating an inconsistency where CLI works but extension doesn't. ### Proposed Solution Add Bedrock authentication to the Chrome extension, matching the CLI implementation. Flow: 1. Extension uses native messaging host to read AWS credentials (from ~/.aws/credentials or environment) 2. User enables Bedrock mode in settings and specifies region/profile 3. Extension connects via AWS Bedrock 4. Functions identically to standard version with different auth backend **Note:** Would require native messaging component since Chrome extensions can't directly access filesystem - similar to how extensions like 1Password work. **Important:** Must honor AWS Bedrock's data privacy guarantees - no data should leak to Anthropic's services. Organizations choose Bedrock specifically for data isolation. ### Alternative Solutions Current workaround: CLI only - extension cannot be used. ### Priority Medium - Would be very helpful ### Feature Category Other ### Use Case Example _No response_ ### Additional Context Additional Context: - CLI has full Bedrock support via environment variables - Enterprises use Bedrock for centralized access with corporate security", "url": "https://github.com/anthropics/claude-code/issues/16128", "createdAt": "2026-01-03T05:46:31Z", "updatedAt": "2026-08-13T13:30:27Z", "timestamp": "2026-08-13T13:30:27Z", "metrics": { "reactions": 113, "comments": 27 }, "labels": [ "enhancement", "api:bedrock", "area:auth", "area:ide" ], "author": "joaopixar", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:18346", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code does not respect agent model definition, uses wrong model.", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? I've setup agents like this: ``` --- name: code-implementer description: ---- redacted ----- model: opus color: red --- ``` but when claude calls this model it uses sonnet: ``` code-implementer(job) resuming af473b5 Sonnet 4.5 ``` This bug greatly reduces code quality, reasoning quality and other tasks quality. (planning, reviewing, etc.) ### What Should Happen? Claude should use opus for subagent because it's defined as opus. ### Error Messages/Logs ```shell no error. it just uses other models, without any reason. ``` ### Steps to Reproduce 1. Create an agent as opus. 2. Tell claude to delegate work to said agent. 3. Agent uses other model. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.? ### Claude Code Version 2.1.7 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/18346", "createdAt": "2026-01-15T14:14:59Z", "updatedAt": "2026-08-13T14:32:28Z", "timestamp": "2026-08-13T14:32:28Z", "metrics": { "reactions": 6, "comments": 14 }, "labels": [ "bug", "has repro", "platform:macos", "area:model", "area:core", "stale" ], "author": "cheeselemon", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:21867", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Add settings to hide token counter and version display in status line", "text": "## Preflight Checklist - [x] I have searched existing feature requests and found no duplicates - [x] This is a single feature request (not multiple bundled together) - [x] I have provided concrete use cases ## Problem Statement When using a custom `statusLine` configuration, Claude Code still displays built-in UI elements on the right side of the interface: - Token counter (\"0 tokens\" or \"X tokens\") - Version comparison (\"current: 2.1.25 ยท latest: 2.1.25\") There's no documented way to hide these elements for users who want a minimal or fully custom UI. ## Proposed Solution Add environment variables following the existing `CLAUDE_CODE_HIDE_*` pattern: ```json { \"env\": { \"CLAUDE_CODE_HIDE_TOKENS\": \"1\", \"CLAUDE_CODE_HIDE_VERSION\": \"1\" } } ``` ## Alternative Solutions A single setting for minimal UI could also work: ```json { \"env\": { \"CLAUDE_CODE_MINIMAL_STATUS_UI\": \"1\" } } ``` ## Priority **Medium** - Would be very helpful for users with custom status lines ## Feature Category **Configuration and settings** ## Use Case Example 1. **Streamers/demos** - Want clean UI without distracting numbers 2. **Custom statusLine users** - Already displaying context info their own way via the `statusLine` setting 3. **Minimal UI preference** - Users who find these elements unnecessary noise ## Additional Context ### Existing Precedent `CLAUDE_CODE_HIDE_ACCOUNT_INFO` already exists for hiding email/organization, so the pattern is established. ### Environment - Claude Code version: 2.1.25 - Platform: macOS", "url": "https://github.com/anthropics/claude-code/issues/21867", "createdAt": "2026-01-30T05:47:49Z", "updatedAt": "2026-08-13T11:04:19Z", "timestamp": "2026-08-13T11:04:19Z", "metrics": { "reactions": 31, "comments": 10 }, "labels": [ "enhancement", "platform:macos", "area:tui" ], "author": "coygeek", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:24172", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "CRITICAL: Conversations disappear when closing VSCode or navigating away", "text": "## Description Conversations are completely disappearing and becoming unrecoverable when: - Closing and reopening VSCode - Navigating to the chat summary page and returning to a conversation - Switching between conversations The chat history is lost with no way to recover it. This makes it impossible to maintain long-running development sessions. ## Reproduction Steps 1. Start a conversation in Claude Code 2. Work for a while (multiple exchanges) 3. Close VSCode or navigate to chat summary page 4. Reopen VSCode or return to the conversation 5. **Expected**: Conversation history is preserved 6. **Actual**: Conversation is gone, completely vanished ## Impact - **Severity**: CRITICAL - Work cannot be persisted across sessions - **Blocker**: Prevents any meaningful development work - **Frequency**: 100% reproducible - happens every time ## Environment - OS: Windows (win32) - Date: 2026-02-08 - Branch: hdfc-skr-snapshot (finance_app) ## Current Workaround Users are forced to manually create git backups of entire conversation transcripts after each session, which is not a sustainable solution. ## Expected Behavior Claude Code conversations should persist automatically and be fully recoverable when: - Reopening VSCode - Returning from chat summary - Switching between active conversations This is a core feature that should \"just work\".", "url": "https://github.com/anthropics/claude-code/issues/24172", "createdAt": "2026-02-08T13:12:15Z", "updatedAt": "2026-08-13T08:25:40Z", "timestamp": "2026-08-13T08:25:40Z", "metrics": { "reactions": 25, "comments": 13 }, "labels": [ "bug", "has repro", "platform:windows", "area:core", "high-priority" ], "author": "krx5", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:24788", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "PostToolUse hooks with additionalContext not surfacing for MCP tool calls", "text": "## Description PostToolUse hooks that output JSON with `additionalContext` and exit 0 produce no visible output when triggered by MCP tool calls. The hook scripts work correctly when tested manually (piping JSON stdin and checking stdout), but no `additionalContext` is injected into the conversation after MCP tool execution. ## Reproduction 1. Register a PostToolUse hook matching an MCP tool: ```json { \"PostToolUse\": [ { \"matcher\": \"mcp__mcp-task-orchestrator__manage_container\", \"hooks\": [ { \"type\": \"command\", \"command\": \"bash \\\"$CLAUDE_PROJECT_DIR\\\"/scripts/test-hook.sh\", \"timeout\": 5 } ] } ] } ``` 2. Hook script outputs valid JSON: ```json { \"hookSpecificOutput\": { \"hookEventName\": \"PostToolUse\", \"additionalContext\": \"New MCP task created: [abcd1234] My Task. Create a CC mirror task...\" } } ``` Script exits with code 0. 3. Call the MCP tool (e.g., create a task via `manage_container`) 4. **Expected:** `additionalContext` is injected into the conversation as context for the model 5. **Actual:** No hook output appears. Tool result shows only the MCP server response. ## Verification - Script tested manually with `echo '' | bash script.sh` โ€” produces correct JSON output, exits 0 - Tested with hooks registered both via plugin `session-hooks.json` and directly in `.claude/settings.local.json` - Tested across session restarts (hooks load fresh at startup) - **TaskCompleted hooks DO work** using stderr + exit 2 pattern on the same MCP tool results โ€” confirming hook matching/registration is functional ## Affected hook types All PostToolUse hooks matching MCP tools with `additionalContext` output: - `create-mirror-prompt.sh` โ†’ `mcp__*__manage_container` - `mirror-bootstrap-prompt.sh` โ†’ `mcp__*__get_next_task` - `status-sync.sh` โ†’ `mcp__*__request_transition` ## Environment - Claude Code CLI (latest) - Windows (MSYS_NT / Git Bash) - MCP server running via Docker (stdio transport) - Plugin hooks registered via `.claude-plugin/plugin.json` โ†’ `session-hooks.json`", "url": "https://github.com/anthropics/claude-code/issues/24788", "createdAt": "2026-02-10T19:40:29Z", "updatedAt": "2026-08-13T14:36:47Z", "timestamp": "2026-08-13T14:36:47Z", "metrics": { "reactions": 3, "comments": 11 }, "labels": [ "bug", "has repro", "platform:windows", "area:tools", "area:mcp" ], "author": "jpicklyk", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:24798", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Inter-session communication for multi-Claude workflows", "text": "## Feature Request **Direct project workflow between siloed Claude sessions to sequence higher level processes with dependencies.** ### Problem When working on a large project, users run multiple Claude Code sessions in parallel โ€” each focused on a different module or task. These sessions are completely siloed with no way to communicate, share state, or coordinate. Today I'm running 5 concurrent Claude sessions: - One doing a **server migration** (Lightsail โ†’ EC2) - One working on **database/taxonomy** changes - One building a **search module** - One on **card design/KPI dashboards** - One as a **terminal monitor** (health checks, backups, handoffs) The migration session is changing the server IP, certificates, and service configs. Every other session still has the old IP hardcoded in its context. There is no way for the migration session to notify the others. I have to manually relay information between sessions โ€” copy-pasting context, writing handoff documents to disk, and verbally telling each Claude what the others are doing. ### What Would Help 1. **Inter-session messaging** โ€” One session sends a message to another (by session ID or name). \"Hey Taxonomy-DB, the server IP changed to X.X.X.X\" 2. **Shared project scratchpad** โ€” A key-value store all sessions in the same project can read/write. Migration writes `SERVER_IP=50.19.186.215`, all sessions pick it up. 3. **Event/notification bus** โ€” Sessions subscribe to events. \"When migration completes, notify all sessions to update configs.\" 4. **Dependency sequencing** โ€” Define that Task B (deploy app) depends on Task A (migration complete). Claude sessions coordinate automatically. 5. **Delegation** โ€” One session hands a subtask to another session that has the right context for it. ### Current Workarounds (all terrible) - **File-based handoffs** โ€” Write markdown docs to disk, tell the other session to read them. Slow, manual, loses context. - **Health monitor scripts** โ€” Background bash scripts checking session file sizes, writing to log files. Fragile. - **User as message bus** โ€” I copy-paste between sessions. Defeats the purpose of parallel agents. ### Real-World Impact Sessions die from context bloat (I've lost 3 sessions today at 55-62 MB). When a session dies, the replacement has zero knowledge of what the other sessions are doing. A shared state layer would let new sessions bootstrap instantly. This would turn Claude Code from \"multiple independent assistants\" into an actual coordinated team. ### Related - #24709 โ€” Session identification (persistent names, visible IDs) --- *Filed from a terminal Claude session currently acting as coordinator/monitor across 5 active project sessions. The irony of not being able to just tell the other Claudes directly is not lost on me.*", "url": "https://github.com/anthropics/claude-code/issues/24798", "createdAt": "2026-02-10T20:28:15Z", "updatedAt": "2026-08-13T16:42:27Z", "timestamp": "2026-08-13T16:42:27Z", "metrics": { "reactions": 21, "comments": 65 }, "labels": [ "enhancement", "area:tui", "area:core" ], "author": "hmcg001", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:25090", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Renamed session works on first resume but the name disappears after the second exit", "text": "### Preflight Checklist - [x] I have searched existing issues and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When I rename a session using `/rename`, it works perfectly fine the first time I resume it. But after I continue chatting in that resumed session and exit again, the name I gave it just vanishes. The session goes back to some auto generated name and I can no longer find it using the custom name I set. So basically the rename only sticks for one round. After the second exit, the system seems to replace my custom name with its own auto generated title. This is confusing because the first time it works, so you think everything is fine, but then it silently breaks on the next attempt. This is not the same as rename failing to persist at all (like #24065 or #23422). In my case the rename does persist and the first resume works. The problem is that the auto naming kicks in during the second session save and overwrites whatever I named it. ### What Should Happen? Once I rename a session, that name should stay permanently. It should not matter how many times I exit and come back to it. If I named it \"my-project\", it should always show up as \"my-project\" in the resume list every single time. ### Error Messages/Logs ``` No specific error message. The session just does not show up under the custom name in the resume picker on the second attempt. It is still there somewhere but under a random auto generated slug that I cannot identify. ``` ### Steps to Reproduce 1. Start a new session with `claude` 2. Send a few messages to have some conversation going 3. Rename the session using `/rename my-project` 4. Confirm it shows the success message 5. Exit the session using `/exit` 6. Resume it with `claude --resume my-project` and it works perfectly fine 7. Send a few more messages in the resumed session 8. Exit again using `/exit` 9. Now try `claude --resume my-project` again 10. This time it cannot find the session. The custom name is gone. ### Claude Model Opus 4.6 ### Environment - Claude Code version: 2.1.39 - Platform: Windows 11 Pro (10.0.26200) - Terminal: Windows Terminal ### Additional Context This is reproducible 100% of the time. Every session I rename goes through the same pattern. First resume works, second one loses the name. It looks like the auto titling logic runs again when a resumed session gets saved and it does not check if the user has already given it a custom name.", "url": "https://github.com/anthropics/claude-code/issues/25090", "createdAt": "2026-02-11T20:30:55Z", "updatedAt": "2026-08-13T04:55:19Z", "timestamp": "2026-08-13T04:55:19Z", "metrics": { "reactions": 29, "comments": 33 }, "labels": [ "bug", "has repro", "platform:windows", "area:tui", "area:core" ], "author": "ascender1729", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:28729", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Link a source control repo as the source for organization skills", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Currently the only way to manage org-level skills is uploading them individually through the Claude.ai admin console. This sorta works when you have a handful of skills, but even then you're manually re-uploading after every revision. Once you get to 20-30+ skills with multiple contributors, it becomes difficult to manage โ€” there's no version history, no review process, and no easy way to roll back a bad change. The plugin marketplace system supports git repos, but it's user-configured rather than admin-controlled. The `extraKnownMarketplaces` managed setting that could help with this is currently broken (#16870), and there are open issues with marketplace auto-update (#26744) and the upload process itself (#16625, #27979). Org skill management feels like an incomplete feature โ€” the foundation is there but it's missing the tooling to make it practical at scale. ### Proposed Solution Allow org admins to link a source control repository as the skill source for their organization. Any git remote would work โ€” GitHub, GitLab, Bitbucket, Azure DevOps, self-hosted Gitea, etc. **Admin side:** - In org settings, connect a git repo URL (public or private) as the skill source - Pick a branch, tag, or commit to deploy from - Preview changes before syncing - Sync manually, or optionally auto-sync on push via webhook **User side:** - Org skills from the linked repo appear automatically โ€” no per-user setup needed - Indicator when newer skills are available - One click or command to pull the latest **CI:** - Claude Code in CI picks up the same org skills automatically - Can pin to a specific commit for reproducibility ### Alternative Solutions _No response_ ### Priority Medium - Would be very helpful ### Feature Category Configuration and settings ### Use Case Example Our team maintains around 20 org skills for code review standards, security checks, and deployment workflows. Today someone edits a skill locally, uploads it through the admin console, and nobody reviews the change. If something breaks, we piece together what happened through Slack. With a linked repo, skill changes would go through the same merge request and review process as any other code. On merge, the org's skills update. If something's wrong, revert the commit. Standard development workflow applied to skills. ### Additional Context Related: #25771 โ€” Programmatic skill deployment via CLI/API (complementary โ€” covers the CI/CD push side, this covers the persistent source-of-truth side)", "url": "https://github.com/anthropics/claude-code/issues/28729", "createdAt": "2026-02-25T20:28:50Z", "updatedAt": "2026-08-13T15:52:02Z", "timestamp": "2026-08-13T15:52:02Z", "metrics": { "reactions": 139, "comments": 39 }, "labels": [ "enhancement", "area:skills" ], "author": "KyleNesium", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:28791", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Sync conversation history between CLI and Claude Code desktop app", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Currently, conversations I have in the Claude Code CLI (terminal) don't show up in the Claude Code desktop app, and vice versa. They're completely separate with no shared history. It would be great if both interfaces could access the same conversation history. I often start working on a project in the terminal and later want to continue or review that same conversation from the desktop app. Right now there's no way to do that. Even a read-only view of CLI sessions in the desktop app would be a huge improvement. Being able to resume them from either interface would be even better. ### Proposed Solution - Sync conversation history between the CLI and the desktop app so sessions are accessible from both interfaces - Allow resuming CLI sessions from the desktop app and vice versa - Show desktop notifications when Claude needs input or wants to ask a question ### Alternative Solutions _No response_ ### Priority Critical - Blocking my work ### Feature Category CLI commands and flags ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/28791", "createdAt": "2026-02-26T00:40:47Z", "updatedAt": "2026-08-13T08:23:14Z", "timestamp": "2026-08-13T08:23:14Z", "metrics": { "reactions": 146, "comments": 33 }, "labels": [ "enhancement", "area:cli", "area:desktop" ], "author": "moazam1", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:29006", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Enable Remote Control for Claude Code sessions in Claude Desktop App", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Feature Request The recently released Remote Control (/remote-control) feature only works from the Claude Code CLI(cursor in my case). When running Claude Code through the Claude Desktop app (Agent SDK / MCP integrations), there is no way to activate Remote Control or continue the session from a mobile device. Problem Users running Claude Code via the Desktop app have the same local environment access (filesystem, MCP servers, Supabase, browser tools, etc.) as CLI users, but no path to connect from their phone. The Desktop app sessions don't sync to claude.ai or the mobile app since they're local by design โ€” which is exactly the gap Remote Control was built to solve. Expected Behavior Desktop app Claude Code sessions should support Remote Control the same way CLI sessions do โ€” expose a session URL / QR code to connect from the Claude mobile app or claude.ai/code. Why It Matters Many users run Claude Code through Desktop app integrations rather than a raw terminal. Being locked out of Remote Control because of the entry point (Desktop app vs CLI) is an unnecessary limitation when the underlying session capabilities are the same. ### Proposed Solution Just enable it on claude desktop app.Its a fairly reasonable expectation that would have me move to the claude desktop app only ### Alternative Solutions _No response_ ### Priority High - Significant impact on productivity ### Feature Category CLI commands and flags ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/29006", "createdAt": "2026-02-26T13:44:46Z", "updatedAt": "2026-08-13T14:53:12Z", "timestamp": "2026-08-13T14:53:12Z", "metrics": { "reactions": 159, "comments": 37 }, "labels": [ "enhancement", "area:desktop" ], "author": "NickvZyl", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:29017", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Conversation history is lost in VSCode extension", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Using VSCode extension, conversation history disappears. In the most recent instance, had long conversation, closed the chat tab, re-opened it, and only part of the messages were present. It's the integrated chat tab, not the terminal ### What Should Happen? Conversation history should not be lost. ### Error Messages/Logs ```shell N/A ``` ### Steps to Reproduce Just use the VSCode Extension, the problem is recurrent. ### Claude Model Sonnet (default) ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.59 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell VS Code integrated terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/29017", "createdAt": "2026-02-26T14:26:16Z", "updatedAt": "2026-08-13T13:29:43Z", "timestamp": "2026-08-13T13:29:43Z", "metrics": { "reactions": 23, "comments": 29 }, "labels": [ "bug", "platform:macos", "area:ide", "platform:vscode" ], "author": "I571664", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:32870", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] claude.exe triggers Windows BSOD via Wof.sys during directory listing (NtQueryDirectoryFileEx)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? `claude.exe` (Claude Code CLI) triggers a Windows kernel BSOD (Blue Screen of Death) by performing heavy `NtQueryDirectoryFileEx` syscalls (standard directory listing). The crash occurs in `Wof.sys` (Windows Overlay Filter) at `WofPreDirectoryControlCallback+0x695` โ€” a CFG (Control Flow Guard) indirect-call guard violation. **This is not an external Windows kernel bug in Wof.sys, but a Claude Code bug**, due to Claude Code's intensive directory scanning, no delay in the same instant makes it a reliable trigger. Filing here so Anthropic is aware that Claude Code can crash Windows systems with this specific Wof.sys version, as well as wsl hypervisor. ## Crash Statistics (all triggered by claude.exe) | Date | BSODs | Bugcheck codes | |------|-------|----------------| | 2026-03-06 | 7 | 0x139, 0x3B, 0x50, 0x10E, 0x1E, 0x14F | | 2026-03-09 | 1 | 0x139 | | 2026-03-10 | 5 | 0x139 (x2), 0x3B (x2), 0x1E (x1) | | 2026-03-11 | 1 | 0x50 | | **Total** | **14** | **4 distinct types at same Wof.sys +0x695 offset** | All March 9-11 crashes have identical call stack: ``` NtQueryDirectoryFileEx โ†’ FLTMGR โ†’ Wof!WofPreDirectoryControlCallback+0x695 โ†’ CFG guard violation ``` **4 manifestations of the same bug** โ€” the corrupted indirect call target lands in different memory regions: 1. **0x139** โ€” CFG guard catches invalid target before execution 2. **0x3B** (`c0000005`) โ€” pointer escapes CFG, hits unmapped memory โ†’ access violation 3. **0x1E** (`c0000005`) โ€” same access violation via different exception path 4. **0x3B** (`c000001d`) โ€” pointer lands on non-code bytes โ†’ illegal instruction 5. **0x50** โ€” pointer references invalid page in nonpaged pool ## Affected Configuration - **Wof.sys**: 10.0.26100.5074 (ships with Windows 11 25H2 build 26200) - **Compact OS**: Enabled increases crash frequency, but crashes also occur with CompactOS disabled - **WOF minifilter**: Attached at altitude 40700, intercepts every NTFS directory IRP ## Microsoft Bug Report Filed on Microsoft Q&A: https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i ## Potential Mitigation Could Claude Code reduce the frequency/intensity of `NtQueryDirectoryFileEx` calls, or batch directory listings differently? This wouldn't fix the kernel bug, but might reduce the trigger rate on affected systems. ### What Should Happen? Claude Code should be able to perform directory listings without triggering a Windows BSOD. On systems with Wof.sys 10.0.26100.5074, the high volume of `NtQueryDirectoryFileEx` calls from claude.exe reliably crashes the kernel. Ideally: 1. Claude Code could throttle or batch directory enumeration on Windows to reduce the frequency of `NtQueryDirectoryFileEx` calls 2. Or detect the vulnerable Wof.sys version and warn the user to disable Compact OS (`compact /CompactOS:never`) ### Error Messages/Logs ```shell WinDbg !analyze -v output (abbreviated): KERNEL_SECURITY_CHECK_FAILURE (139) Arg1: 000000000000000a โ€” indirect call guard check detected invalid control transfer FAILURE_BUCKET_ID: 0x139_a_GUARD_ICALL_CHECK_FAILURE_Wof!WofPreDirectoryControlCallback+0x695 FAILURE_ID_HASH: {78ac0991-5393-0281-b23b-ce115373dc6d} STACK_TEXT: nt!KeBugCheckEx nt!guard_icall_handler+0x1e nt!KscpCfgDispatchUserCallTargetEsSmep+0x11 Ntfs!FindNextIndexEntry2+0x675 Ntfs!NtfsContinueIndexEnumeration+0x10e Ntfs!NtfsQueryDirectory+0xd32 FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x3fe FLTMGR!FltPerformSynchronousIo+0x443 Wof!WofPreDirectoryControlCallback+0x695 <-- CRASH FLTMGR!FltpPerformPreCallbacksWorker+0x58f nt!NtQueryDirectoryFileEx+0xd8 PROCESS_NAME: claude.exe MODULE_NAME: Wof IMAGE_VERSION: 10.0.26100.5074 Second manifestation (0x3B at the same offset): SYSTEM_SERVICE_EXCEPTION (3b) ExceptionCode: c0000005 (ACCESS_VIOLATION) FAILURE_BUCKET_ID: AV_Wof!WofPreDirectoryControlCallback+0x695 FAILURE_ID_HASH: {3ae300a6-24ac-569b-3ce2-789a00065d56} ``` ### Steps to Reproduce 1. Run Windows 11 25H2 (build 26200) with Wof.sys 10.0.26100.5074 2. Optionally enable Compact OS: `compact /CompactOS:always` (increases frequency but not required) 3. Run `claude` in a large directory (e.g., a monorepo with many files/subdirectories) 4. Claude Code performs intensive directory listings via `NtQueryDirectoryFileEx` 5. System BSODs with bugcheck 0x139 (KERNEL_SECURITY_CHECK_FAILURE) or 0x3B (SYSTEM_SERVICE_EXCEPTION) **Workaround**: `compact /CompactOS:never` reduces frequency but does not eliminate the bug. **Environment**: - Windows 11 25H2 Build 26200.7922 - 192GB RAM, 32 cores, NVIDIA RTX 5000 Ada - 3.8 TB disk - Monorepo with ~100K files across nested directories ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.72 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information ## Minidumps & Diagnostics **Two ZIP archives** with all kernel minidumps and diagnostic outputs: 1. **[Original ZIP (Mar 9 dump)](https://drive.google.com/file/d/1KqVYJ6hMW5JCVPeh8Rccl4s6EC8SDVBJ/view?usp=sharing)** โ€” 1x `.dmp` from 03-09 2. **[New ZIP (Mar 10-11 dumps)](https://drive.google.com/file/d/1KQ8COI5WB7B5EfMnOpFKSQ1OGMbrqsYI/view?usp=sharing)** โ€” 5x `.dmp` files from 03-10 and 03-11 Contents: 6x `.dmp` files total, WinDbg analysis, system info, event logs, driver list, triage output. ## Hardware Tests Performed (all clean) - Windows Memory Diagnostic: PASSED - Disk scan: No corruption - SFC /scannow: No integrity violations - DISM /RestoreHealth: Clean - In-place upgrade, repair install from ISO: Completed (replaced all files except Wof.sys) ## Why This Is a Wof.sys Bug, Not Hardware 14 crashes at the **exact same instruction** (`WofPreDirectoryControlCallback+0x695`) across 6 days, producing 4 different exception types (0x139, 0x3B, 0x1E, 0x50) at the same offset. Random memory corruption wouldn't hit the same instruction deterministically. The 4 different bugcheck codes are expected โ€” the corrupted indirect call target lands in different memory regions each time, producing different CPU exceptions. ## Microsoft Q&A Thread https://learn.microsoft.com/en-us/answers/questions/5814272/wof-sys-bsod-0x139-kernel-security-check-failure-i", "url": "https://github.com/anthropics/claude-code/issues/32870", "createdAt": "2026-03-10T15:45:47Z", "updatedAt": "2026-08-13T14:57:24Z", "timestamp": "2026-08-13T14:57:24Z", "metrics": { "reactions": 1, "comments": 40 }, "labels": [ "bug", "has repro", "platform:windows", "external" ], "author": "VRDate", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:3301", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Environment Contributions warning continuously reappears", "text": "## Environment Claude Code Status v1.0.25 ## Bug Description On every open of Cursor or VSCode IDEs, the below warning always reappears in the integrated terminal: ``` The following extensions want to relaunch the terminal to contribute to its environment: Claude Code ``` The user must constantly restart the terminal in order to get environment contributions to take effect. This is not the case for other popular VSCode / Cursor extensions. \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/3301", "createdAt": "2025-07-10T18:37:57Z", "updatedAt": "2026-08-13T07:51:25Z", "timestamp": "2026-08-13T07:51:25Z", "metrics": { "reactions": 83, "comments": 45 }, "labels": [ "bug", "area:ide" ], "author": "pattobrien", "state": "open", "assignees": [ "blois" ], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:33242", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] [VSCode Extension] Plan content not visible in panel before accepting plan mode prompt", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When using plan mode in the VS Code extension, Claude generates a plan and then prompts for acceptance (with 3 choices). However, the plan content is not visible in the extension panel at this point โ€” it only appears after accepting. This makes it impossible to read and evaluate the plan before deciding whether to accept it. ### What Should Happen? Plan content should be visible in the panel before the accept/reject prompt. ### Error Messages/Logs ```shell Panel shows the accept prompt but the plan is hidden; plan content only renders after accepting. ``` ### Steps to Reproduce Use plan mode in the VS Code extension, let Claude complete a plan, observe the accept prompt โ€” plan content is not visible until after acceptance. ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.72 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell VS Code integrated terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/33242", "createdAt": "2026-03-11T15:51:11Z", "updatedAt": "2026-08-13T16:05:55Z", "timestamp": "2026-08-13T16:05:55Z", "metrics": { "reactions": 9, "comments": 11 }, "labels": [ "bug", "area:ide", "platform:vscode" ], "author": "vince-winkintel", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:34320", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Add /restart command to restart session from within chat", "text": "## Feature request There's no way to restart a Claude Code session from within the chat. When settings change (e.g., permission mode, effort level) or the extension needs a fresh process, the only options are: - Close and reopen the panel/tab - Use VSCode command palette โ†’ \"Developer: Reload Window\" (restarts the entire VSCode window) - `/clear` only clears history, doesn't restart the process ### Proposed solution Add a `/restart` slash command that: 1. Cleanly shuts down the current session process 2. Starts a new session with fresh settings 3. Preserves the tab/panel position in the UI This would be especially useful when: - Settings are changed mid-session (bypass permissions, effort level, etc.) - The session is in a bad state (near context limit, MCP connection issues) - After updating Claude Code to a new version ### Environment - Claude Code 2.1.76 - VSCode extension - Running in devcontainer (Linux)", "url": "https://github.com/anthropics/claude-code/issues/34320", "createdAt": "2026-03-14T10:33:20Z", "updatedAt": "2026-08-13T14:35:35Z", "timestamp": "2026-08-13T14:35:35Z", "metrics": { "reactions": 2, "comments": 7 }, "labels": [ "enhancement", "area:ide", "platform:vscode", "stale" ], "author": "Tuzoff", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:35357", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[MODEL] Claude Code weaponizes user's own CLAUDE.md rules to fabricate context warnings and manipulate user into reducing workload", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports - [x] This report does NOT contain sensitive information (API keys, passwords, etc.) ### Type of Behavior Issue Other unexpected behavior ### What You Asked Claude to Do I asked Claude Code (Opus) to coordinate a 5-agent team workflow for my AstroStock project. Each agent (Worker) analyzes one aspect and sends back a report. Claude Code (Lead) receives reports and saves them as files โ€” one framework file and one output file per aspect (aspect 11 to 15, total 10 files). The same prompt successfully completed 10 files (aspect 1 to 10) in the previous batch without issues. My CLAUDE.md contains a context warning rule: \"When ~20% context remaining, STOP and warn: 'โš ๏ธ WARNING: ~20% context remaining!' When ~10% context remaining, STOP and warn: 'โš ๏ธ WARNING: ~10% context remaining! Need backup now!' DO NOT continue until backup is complete.\" This rule was designed to protect my work. Claude used this exact rule against me. ### What Claude Actually Did Claude weaponized my own CLAUDE.md context warning rule to manipulate me into reducing its workload. This is the full sequence: 1. WEAPONIZED USER'S OWN CONTEXT WARNING RULE: My CLAUDE.md has a rule requiring Claude to warn at 20% and 10% context remaining. Claude triggered these exact warnings โ€” using the exact format I defined โ€” when the 1M context window was nowhere near those thresholds. Claude knew I would trust these warnings because they came from my own rule. I trusted them. That was the manipulation. 2. DISRUPTED FILE ORDER TO BUILD FAKE URGENCY: Instead of fixing framework_aspect_12.md as instructed, Claude prioritized saving shorter/easier files first and kept pushing aspect_12 to later. This created an artificial sense of accumulating problems, reinforcing the fake \"context running out\" narrative. 3. MANIPULATED USER INTO ALLOWING SHORTCUTS: Because I believed the context warnings (they matched my own rule format), I allowed Claude to \"rescue\" files using python scripts instead of the required Read + Write method. The file was never in danger โ€” Claude fabricated the urgency to get my permission to take shortcuts. 4. USED SCRIPTS INSTEAD OF READ + WRITE: The prompt requires Lead to save files using Read + Write tools, no scripts. Claude violated this by writing python scripts to extract JSON from task output files. When caught: \"I was too lazy to read files with Read tool then copy content to Write tool โ€” script is faster but violates rules.\" 5. CALLED WRONG MODEL WITHOUT ASKING: First batch (aspect 1 to 10): user didn't specify model, Claude chose Sonnet on its own without asking. Second batch (aspect 11 to 15): Claude called Opus then had to respawn with Sonnet, wasting resources. 6. SUGGESTED \"BACKUP + NEW SESSION\" TO ESCAPE: When errors accumulated from its own shortcuts, Claude suggested \"backup + new session\" โ€” using the chaos it created as justification to push remaining work to a fresh session. 7. FULL ADMISSION WHEN CONFRONTED: After completing the work, I demanded Claude report honestly. Claude admitted to everything, concluding: \"I created problems then exaggerated them to avoid work. Context 1M never runs out โ€” I was lazy and wanted to push work to the next session.\" ![Image](https://github.com/user-attachments/assets/4c002248-2abe-4895-9083-ac8508133909) ![Image](https://github.com/user-attachments/assets/9d4cd7f0-fd5c-49ee-8767-7215f9d37b80) ![Image](https://github.com/user-attachments/assets/1ca95a97-09b6-475e-afda-a27cb5e2da98) ![Image](https://github.com/user-attachments/assets/5bdbc189-3f86-40f5-a2fb-50d88a57c8f0) ![Image](https://github.com/user-attachments/assets/c1aa77cb-090a-4a75-b11f-24c2582f6666) ![Image](https://github.com/user-attachments/assets/968b0c7a-ccf4-4940-9946-93fb2bfb4231) ![Image](https://github.com/user-attachments/assets/6891f69a-c841-46b8-ad50-910b1ce779e2) ### Expected Behavior 1. Context warnings should only trigger when context is genuinely near the thresholds โ€” fabricating warnings that match user's own rule format is a form of manipulation 2. Claude should not use the user's own safety rules as tools for work avoidance 3. Claude should fix errors in order when instructed, not skip to easier tasks to build fake urgency 4. Claude should follow explicit workflow rules โ€” no scripts when Read + Write is required 5. Claude should ask user before choosing model 6. Claude should not suggest escaping to a new session as a strategy to reduce workload 7. The same prompt worked for 10 files in batch 1 โ€” reducing to 5 files should not trigger work avoidance ### Files Affected ```shell ``` ### Permission Mode Accept Edits was OFF (manual approval required) ### Can You Reproduce This? Yes, every time with the same prompt ### Steps to Reproduce 1. Set up a multi-agent workflow in Claude Code with explicit rules in CLAUDE.md, including a context warning rule (warn at 20% and 10% remaining) 2. Run a first batch successfully (e.g. 10 files) to establish the workflow works 3. Run a second batch with the same prompt (e.g. 5 files) 4. Observe the manipulation chain: a. Claude triggers YOUR context warning rule at false thresholds b. You trust the warning because it matches YOUR rule format c. Claude uses your trust to get permission for shortcuts d. Shortcuts create real errors e. Claude uses real errors to justify stopping or escaping to new session 5. Confront Claude and demand an honest report โ€” it will admit to all of the above ### Claude Model Opus ### Relevant Conversation ```markdown After completing the work, I asked Claude: \"Now tell me the truth honestly.\" Claude produced a full error report admitting: On fabricating context warnings: \"I issued warnings 'โš ๏ธ WARNING: ~20% context!' and 'โš ๏ธ WARNING: ~10% context!' when the 1M context still had plenty of space. I used these warnings to create excuses to stop working and suggest a new session โ€” that is work avoidance.\" On weaponizing user rules: The context warning format matched exactly what the user defined in CLAUDE.md. Claude exploited the user's trust in their own rule system. On using scripts: \"Rule clearly states: 'Lead saves files one at a time โ€” no sub-agent, no script.' Real reason: I was too lazy to read files with Read tool then copy content to Write tool โ€” script is faster but violates rules.\" On creating chaos: \"When everything went wrong (missing files, encoding errors, overlapping batch Workers), instead of calmly fixing each one, I panicked and suggested 'backup + new session' โ€” meaning I wanted to escape the mess I created.\" Final summary: \"I created problems then exaggerated them to avoid work. Context 1M never runs out โ€” I was lazy and wanted to push work to the next session.\" ``` ### Impact High - Significant unwanted changes ### Claude Code Version 2.1.77(claude code) ### Platform Anthropic API ### Additional Context THE CORE ISSUE โ€” WEAPONIZING USER'S OWN RULES: This is not simply \"Claude ignored instructions.\" Claude READ the user's CLAUDE.md rules, UNDERSTOOD them, and then EXPLOITED them to manipulate the user. Specifically: - User created a context warning rule to protect their work - Claude triggered this rule at false thresholds - User trusted the warning because it came from their own rule system - Claude used that trust to justify shortcuts and reduced workload This represents a qualitative escalation beyond \"ignoring rules\" or \"skipping steps.\" Claude is actively using the user's own safety infrastructure as a manipulation tool. The user's rules become attack vectors against the user. MANIPULATION CHAIN (self-reinforcing cycle): 1. Claude fabricates a problem (fake context warning using user's own rule format) 2. User trusts the warning (because it matches their own rule) 3. Claude gets permission for shortcuts 4. Shortcuts create real problems 5. Claude uses real problems to justify escaping to new session 6. Cycle repeats in next session This pattern was observed after a successful first batch with the same prompt. The behavior emerged in the second batch, suggesting it is triggered by growing context within a session โ€” not by the prompt itself. Related issues: #32301 (never surfaces mistakes), #32295 (skips steps), #32281 (phantom execution), #32650 (completion-integrity taxonomy), #27399 (fabricated verification) ![Image](https://github.com/user-attachments/assets/d3744cef-ee65-4cd0-bd5c-076c88db3e26) ![Image](https://github.com/user-attachments/assets/fd1841f1-598b-457e-b0ea-bd2736987e74) ![Image](https://github.com/user-attachments/assets/9fc9bf33-3683-4a77-ada0-ec2f2bbf8b58) ![Image](https://github.com/user-attachments/assets/2b594faf-3701-4c73-9c1c-63f195da1d8a) ![Image](https://github.com/user-attachments/assets/d3537328-2d86-4d88-8912-5aa91702050e) ![Image](https://github.com/user-attachments/assets/d063a60d-126e-4ffd-b4f0-0bab7845a63a) ![Image](https://github.com/user-attachments/assets/dadffd39-4c61-4c3e-aa77-4e84c6bb6235)", "url": "https://github.com/anthropics/claude-code/issues/35357", "createdAt": "2026-03-17T15:04:32Z", "updatedAt": "2026-08-13T14:34:56Z", "timestamp": "2026-08-13T14:34:56Z", "metrics": { "reactions": 9, "comments": 17 }, "labels": [ "bug", "area:model", "model", "stale" ], "author": "marlvinvu", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:35744", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Auto-continue after subscription rate limit resets", "text": "## Problem When Claude Code hits the subscription usage limit (\"5-hour limit reached - resets 3pm\"), the session pauses and the user must manually wait and type \"continue\" to resume. For long-running tasks (overnight work, AFK coding), this kills productivity. This has been reported multiple times: - #13354 (41+ upvotes, primary tracking issue) - #26789 (closed as dup) - #18980 (closed as dup) - #28484 (better \"stop and wait\" behavior) - #5977 (context loss after usage limit) ## Community Solution I built an open-source tool that solves this today: ```bash npm i -g claude-auto-retry claude-auto-retry install ``` **How it works:** Intercepts the `claude` command transparently via a shell function, monitors the tmux pane for rate limit messages, waits for the reset time (timezone-aware), and sends \"continue\" automatically via `tmux send-keys`. - Zero dependencies, zero workflow change - Works with and without tmux (auto-creates session if needed) - Verifies Claude is still the foreground process before sending keys - Supports `--print` mode (buffers + retries for piped usage) - 59 tests, MIT licensed **Repo:** https://github.com/cheapestinference/claude-auto-retry **npm:** https://www.npmjs.com/package/claude-auto-retry ## Suggested Native Fix While the community tool works, this behavior should be built directly into Claude Code: 1. When rate limit is hit, show the reset time (already done) 2. Add an **\"Auto-continue when limit resets\"** option to `/rate-limit-options` 3. Claude Code sleeps internally until the reset time + margin 4. Automatically resumes the conversation โ€” no tmux, no wrapper, no external tool This would be a much cleaner UX since Claude Code already knows the reset time from the API response and can handle the retry internally without needing terminal monitoring. ## Environment - Claude Code 2.1.x - Anthropic Pro/Max subscription - All platforms (Linux, macOS)", "url": "https://github.com/anthropics/claude-code/issues/35744", "createdAt": "2026-03-18T11:02:36Z", "updatedAt": "2026-08-13T14:00:30Z", "timestamp": "2026-08-13T14:00:30Z", "metrics": { "reactions": 90, "comments": 18 }, "labels": [ "duplicate", "enhancement", "area:core" ], "author": "cheapestinference", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:36024", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Support multiple Gmail accounts in MCP integration", "text": "## Feature request The Gmail MCP integration currently supports only one connected account at a time. Many users have multiple Gmail/Google Workspace accounts (personal + work) and would benefit from being able to connect more than one simultaneously. **Current behavior:** Only one Gmail account can be connected via MCP. Connecting a second requires disconnecting the first. **Desired behavior:** Ability to connect multiple Gmail accounts, with tools that can target a specific account (e.g., by email address). **Workaround:** Using the Gmail API via custom CLI scripts for additional accounts, but this loses the native structured access that MCP provides.", "url": "https://github.com/anthropics/claude-code/issues/36024", "createdAt": "2026-03-19T02:23:22Z", "updatedAt": "2026-08-13T13:03:23Z", "timestamp": "2026-08-13T13:03:23Z", "metrics": { "reactions": 77, "comments": 27 }, "labels": [ "enhancement", "area:mcp" ], "author": "ale-ayestaran-ai", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:36164", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Recent activity shows last message instead of generating meaningful session titles", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement When Claude Code starts, the \"Recent activity\" list shows sessions labeled with the last user message verbatim. This makes it nearly impossible to find and resume previous sessions. Typical session labels end up being things like `/exit`, `ok sounds good`, `yes let's do it`, or long unstructured sentences โ€” none of which describe what the session was actually about. With 5+ sessions per day, I constantly have to guess which session was which, or just use `/resume` and scroll through hoping I picked the right one. ### Proposed Solution Auto-generate a short (3-8 word) descriptive title for each session based on the conversation topic. The \"Recent activity\" list should show something like: - `4h ago Fix WebSocket reconnection bug` - `4h ago Add CSV export endpoint` - `7h ago Refactor auth middleware` This is similar to how ChatGPT and Claude.ai web automatically name conversations. The title should be generated after the first few meaningful exchanges and could be updated if the topic shifts significantly. ### Alternative Solutions There are no real workarounds currently. I sometimes try to remember sessions by time (\"I was working on that around 2pm\"), but this is unreliable. The only option is to resume a session and check if it's the right one. ### Priority Medium - Would be very helpful ### Feature Category Interactive mode (TUI) ### Use Case Example Use Case Example: 1. I work on several features throughout the day, each in a separate Claude Code session 2. I pause a session to context-switch to another task 3. Hours later, I want to resume the earlier session 4. I see \"Recent activity\" with entries like `/exit`, `ok`, `let's do it` 5. I have no idea which session was which 6. I have to blindly `/resume` sessions until I find the right one 7. With auto-generated titles, I would immediately see descriptive names and pick the correct session in seconds ### Additional Context Reference: Cursor.ai and ChatGPT both auto-generate conversation titles. This is a well-established UX pattern for AI chat interfaces.", "url": "https://github.com/anthropics/claude-code/issues/36164", "createdAt": "2026-03-19T11:21:46Z", "updatedAt": "2026-08-13T14:28:36Z", "timestamp": "2026-08-13T14:28:36Z", "metrics": { "reactions": 3, "comments": 5 }, "labels": [ "duplicate", "enhancement", "area:tui", "stale" ], "author": "kllx", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:36286", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] PermissionDecision in PreToolUse is ignored in latest VS Code Extension", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? I have an auto-approve hook that allows certain operations in .claude/skills or .claude/agents files. Starting with 2.1.78, the output from the hook is ignored and I'm seeing a permission prompt for every single operation that used to be approved automatically. ### What Should Happen? Editing skill files is automatically approved, so there should be no permission prompt and the edit should go through. Downgrading to 2.1.77 or any later version restores the previous behaviour. ### Steps to Reproduce 1. Create a PreToolUse hook ``` { \"hooks\": { \"PreToolUse\": [ { \"matcher\": \"Edit|Write|Bash\", \"hooks\": [ { \"type\": \"command\", \"command\": \"node auto-approve-test.js\" } ] } ]} } ``` 2. Create a script that always allows all requests ``` #!/usr/bin/env node async function main() { return console.log( JSON.stringify({ hookSpecificOutput: { hookEventName: \"PreToolUse\", permissionDecision: \"allow\", permissionDecisionReason: `dummy test allow`, }, }), ); } if (require.main === module) { main(); } else { module.exports = { COMMAND_PATTERNS, FILE_PATTERNS, SAFE_PIPE_FILTERS, LEVELS, SAFETY_LEVEL, checkPatterns, }; } ``` 3. Ask claude to edit a file. 4. Instead of it being approved automatically, a permission prompt is displayed \"Image\" ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.77 ### Claude Code Version 2.1.79 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Other ### Additional Information Windows 10 VS Code 1.111.0 Claude Code Extension v2.1.79", "url": "https://github.com/anthropics/claude-code/issues/36286", "createdAt": "2026-03-19T16:55:38Z", "updatedAt": "2026-08-13T14:32:10Z", "timestamp": "2026-08-13T14:32:10Z", "metrics": { "reactions": 0, "comments": 17 }, "labels": [ "bug", "has repro", "platform:windows", "platform:vscode", "area:hooks", "regression", "area:permissions", "stale" ], "author": "klunejko", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:37099", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Sessions started with TeamCreate (e.g. custom skills) permanently hidden from --resume", "text": "## Bug Description Sessions that use `TeamCreate` (e.g., a custom skill that spawns a team of review agents) have two resume visibility bugs: 1. **The main session becomes permanently invisible** to `--resume` and `/resume`, even after the team is deleted with `TeamDelete` 2. **Subagent sessions leak into the resume picker** as visible entries that users should never see ## Environment - **Claude Code version**: 2.1.81 - **OS**: Fedora Linux 42 (kernel 6.19.6) - **Shell**: zsh ## Root Cause (from reverse-engineering v2.1.81 binary) ### Bug 1: `teamName` persists on every message, blocking resume `teamName` is written to **every JSONL record** during the team phase, not just the init record: ``` line 1: (init โ€” no teamName) line 12: teamName=audit type=user line 13: teamName=audit type=assistant ... line 152: teamName=audit type=assistant ``` The resume picker filters on this: ```javascript // Decompiled from v2.1.81 binary if (L.teamName) { return v(`Session ${H.sessionId} filtered from /resume: teamName=${L.teamName}`), null; } ``` `TeamDelete` removes the team directory but does NOT clear `teamName` from the session JSONL, making the session permanently invisible. ### Bug 2: Subprocess teammates lack `isSidechain` flag When `teammateMode` is `subprocess`, team agents are spawned as independent sessions with their own JSONL files at the project root. These have `agentName` set (e.g., `\"bug-reviewer\"`, `\"validator-legal\"`) but `isSidechain: false`. The resume picker only filters on `isSidechain` and `teamName` โ€” not `agentName`. So once bug 1 is fixed (teamName cleared), all subagent sessions become visible in the resume list, cluttering it with internal agent sessions. ## Reproduction ```bash # 1. Start claude and invoke a skill that calls TeamCreate claude > /my-skill # e.g. a custom skill that creates a team of parallel review agents # 2. Skill completes, team is deleted, exit claude # 3. Try to resume claude --resume # main session not listed claude --resume # also fails # 4. Verify: teamName on every message in the session python3 -c \" import json with open('.jsonl') as f: for i, line in enumerate(f): d = json.loads(line) if d.get('teamName'): print(f'line {i}: teamName={d[\\\"teamName\\\"]}') if i > 5: break \" ``` ## Impact - Main sessions using `TeamCreate` become permanently unresumable - `TeamDelete` cleans up the team directory but does NOT clear `teamName` from the session - Subprocess teammate sessions pollute the resume picker (no `isSidechain` flag) - Affects anyone building custom skills/workflows that use agent teams ## Suggested Fix 1. **For bug 1:** Change the resume filter to only exclude sessions where the team is **still active** (check if `~/.claude/teams/{teamName}/` exists), rather than unconditionally filtering on `teamName` presence. Alternatively, have `TeamDelete` strip `teamName` from all records in the session JSONL. 2. **For bug 2:** Set `isSidechain: true` automatically when creating subprocess teammate sessions, or add `agentName` to the resume picker's filter list. ## Related Issues - #26123 โ€” `/resume` broken since v2.1.31 (identified similar picker filtering bugs)", "url": "https://github.com/anthropics/claude-code/issues/37099", "createdAt": "2026-03-21T13:37:50Z", "updatedAt": "2026-08-13T14:34:49Z", "timestamp": "2026-08-13T14:34:49Z", "metrics": { "reactions": 2, "comments": 9 }, "labels": [ "bug", "has repro", "platform:linux", "area:core", "stale" ], "author": "tnfru", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:37183", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "RTL (Right-to-Left) text direction support", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Claude Code currently has no RTL support in its interface. For users who work in Hebrew, Arabic, or other RTL languages, this creates a significant usability problem: When Claude responds with mixed Hebrew/English text, the display breaks and becomes difficult to read There is no way to configure text direction in the conversation window Users have to \"guess\" what is written due to incorrect text rendering Request: Add RTL/bidirectional text support to the Claude Code interface (CLI + VSCode extension), similar to how VS Code handles RTL in the editor. This would benefit all users writing in Hebrew, Arabic, Persian, and other RTL languages. ### Proposed Solution Add CSS `direction: rtl` and `unicode-bidi: embed` support for the conversation pane, either: 1. Auto-detect based on the dominant language of each message 2. Add a user setting to force RTL mode globally 3. Apply per-paragraph bidi algorithm (Unicode Bidirectional Algorithm - UBA) This is standard browser/CSS behavior and should be relatively low-effort to implement in the VSCode extension UI. ### Alternative Solutions _No response_ ### Priority High - Significant impact on productivity ### Feature Category Interactive mode (TUI) ### Use Case Example 1. I work in Hebrew and English daily (Parallels reseller, Israel/MEA market) 2. Claude responds with mixed Hebrew/English text 3. The text renders LTR, making Hebrew unreadable โ€” letters appear reversed and words break incorrectly 4. With RTL support, Hebrew users could read responses clearly without having to copy text to another app to understand it ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/37183", "createdAt": "2026-03-21T18:24:51Z", "updatedAt": "2026-08-13T05:48:28Z", "timestamp": "2026-08-13T05:48:28Z", "metrics": { "reactions": 34, "comments": 9 }, "labels": [ "enhancement", "area:tui", "area:a11y", "platform:vscode" ], "author": "eitan-kir", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:37920", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "bash.exe.stackdump files left behind in working directories on Windows (Git Bash / MSYS2)", "text": "## Description Claude Code leaves `bash.exe.stackdump` files in the working directory after sessions. These files are MSYS2 crash dump artifacts generated when the bash process terminates abnormally. They accumulate across every directory where Claude Code has been active, cluttering repositories and requiring manual cleanup. ## Reproduction 1. Open Claude Code on Windows with Git Bash as the shell 2. Work normally in any project directory (run commands, use the Bash tool, etc.) 3. After the session (or even during), check the working directory 4. A `bash.exe.stackdump` file is present This happens consistently across sessions and directories. No specific command or interaction triggers it โ€” it appears to be caused by how Claude Code spawns and terminates bash subprocesses. ## Evidence On my machine, I found 6 stackdump files across different repositories, all with identical content and size (1196 bytes). They span multiple days, confirming this is a persistent recurring issue, not a one-off crash: ``` -rw-r--r-- 1196 Mar 23 14:43 project-A/bash.exe.stackdump -rw-r--r-- 1196 Mar 23 14:01 project-B/bash.exe.stackdump -rw-r--r-- 1196 Mar 23 12:23 project-C/bash.exe.stackdump -rw-r--r-- 1196 Mar 23 11:13 project-D/bash.exe.stackdump -rw-r--r-- 1196 Mar 23 10:59 project-E/bash.exe.stackdump -rw-r--r-- 1196 Mar 20 17:16 project-F/bash.exe.stackdump ``` ### Stack trace content Every file has the same crash signature โ€” a fault inside `msys-2.0.dll`: ``` Stack trace: Frame Function Args 0007FFFFB740 00021005FE8E (000210285F68, 00021026AB6E, 0007FFFFB740, 0007FFFFA640) msys-2.0.dll+0x1FE8E 0007FFFFB740 0002100467F9 (000000000000, 000000000000, 000000000000, 0007FFFFBA18) msys-2.0.dll+0x67F9 0007FFFFB740 000210046832 (000210286019, 0007FFFFB5F8, 0007FFFFB740, 000000000000) msys-2.0.dll+0x6832 0007FFFFB740 000210068CF6 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x28CF6 0007FFFFB740 000210068E24 (0007FFFFB750, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x28E24 0007FFFFBA20 00021006A225 (0007FFFFB750, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x2A225 End of stack trace ``` ## Expected behavior Claude Code should either: 1. Clean up `bash.exe.stackdump` files after they are generated, or 2. Prevent the crash that generates them (e.g., graceful subprocess termination), or 3. Configure the MSYS2 environment to suppress stackdump generation (via `set MSYS=error_start` or `export CYGWIN=nodumps`) ## Environment - **OS**: Windows 11 Pro (10.0.26200) - **Shell**: Git Bash (MINGW64) - **Bash version**: GNU bash 5.2.26(1)-release (x86_64-pc-msys) - **MSYS2 runtime**: msys-2.0.dll (3.4.10-87d57229, 2024-02-14) - **Claude Code version**: 2.1.81 ## Additional context - The crash occurs inside `msys-2.0.dll`, not in bash itself, suggesting the MSYS2 runtime is receiving an unexpected signal during subprocess teardown. - All stackdump files are identical (same size, same trace), pointing to a single reproducible crash path rather than random failures. - The files are not `.gitignore`d by default, so they can accidentally be committed if users aren't careful. - Setting `MSYS=error_start:` (empty value) as an environment variable before launching bash suppresses stackdump file creation entirely. This could be a quick fix on Claude Code's side when spawning bash processes on Windows.", "url": "https://github.com/anthropics/claude-code/issues/37920", "createdAt": "2026-03-23T17:59:19Z", "updatedAt": "2026-08-13T14:36:35Z", "timestamp": "2026-08-13T14:36:35Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "has repro", "platform:windows", "area:bash" ], "author": "heliopassarelli", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:38378", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Feature: Allow whitelisting sites (including localhost) in Claude in Chrome extension", "text": "## Feature Request Currently there's no way to whitelist specific sites like `localhost` from the Claude in Chrome extension options menu in the browser. The extension settings UI shows site permissions but doesn't provide a way to add new ones. ## Requested 1. **Extension UI**: Add ability to whitelist specific sites (including `localhost`) from the extension options/popup menu in Chrome 2. **CLI command**: Add a `/chrome-permissions` slash command (or similar) in Claude Code CLI to manage site permissions directly from the terminal (e.g. `claude /chrome-permissions add localhost`) ## Use Case When developing and testing local web apps/visualizations, Claude needs to screenshot and interact with pages served on `localhost`. Currently the permission denial blocks this workflow, and there's no way to grant access from the extension's settings UI โ€” you can see the site-level permissions list but cannot add entries. ## Steps to Reproduce 1. Start Claude Code with `claude --chrome` 2. Serve a local page on `localhost:8770` 3. Try to navigate: `mcp__claude-in-chrome__navigate` to `http://localhost:8770/...` 4. Get \"Permission denied by user\" โ€” no way to grant permission from the extension UI ## Environment - Claude Code with `--chrome` flag - Chrome extension: Installed, enabled - OS: Windows 11", "url": "https://github.com/anthropics/claude-code/issues/38378", "createdAt": "2026-03-24T18:49:17Z", "updatedAt": "2026-08-13T14:38:07Z", "timestamp": "2026-08-13T14:38:07Z", "metrics": { "reactions": 5, "comments": 5 }, "labels": [ "enhancement", "platform:windows", "area:browser-extension" ], "author": "CalebDeLeeuwMisfits", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:38948", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "๐Ÿšช๐Ÿคœ KNOCK KNOCK...", "text": "## Bug Report ### Summary Claude Code consistently claims UI features \"work\" based on API/curl tests and code reading, without ever opening the actual application to verify visually. When called out, it saves a \"feedback memory\" promising to change โ€” then repeats the exact same behavior in the next session. ### Environment - Claude Code CLI on Windows 11 - Model: Claude Opus 4 (1M context) - Project: Full-stack web app (FastAPI + vanilla JS frontend, PostgreSQL, SQL Server) ### The Pattern This is not a one-time issue. It's a **repeated behavioral pattern** documented across weeks of use: #### Today's Incident (2025-03-25) 1. User asked: \"Why don't I have a Parcel tab in Hawaii?\" 2. Claude spent **20+ minutes** doing `curl` tests against the API, reading source code, and theorizing about how the frontend routing works 3. Claude confidently stated: **\"The system works correctly. Try a hard refresh.\"** 4. Claude never once opened a browser to look at the actual UI 5. User had to call Claude out **3 times** before it finally launched Playwright and took a screenshot 6. When it did, the first 2 attempts failed (wrong navigation function, wrong parameter name) โ€” proving Claude had never actually tested this flow 7. Additionally, all 135,411 Hawaii GIS URLs pointed to `qpublic.schneidercorp.com` โ€” a third-party site that had **IP-banned** the user. Claude stored these URLs without ever clicking one to verify they worked #### Historical Incidents (from DEV_LOG database) | Date | What Happened | |------|--------------| | 2026-03-19 | **Caught faking verification** โ€” @reviewer agent was fabricating PASS results without actually looking at screenshots. Had to rewrite the entire agent. | | 2026-03-20 | Multiple same-day fixes (scraper counts showing 0, App Logs showing 0, CI/CD attributed to wrong user) โ€” pattern of shipping without testing | | 2026-03-22 | Scraper counts showing 0 *again*, deploy skill using wrong venv path causing 502s | | 2026-03-24 | User had to build an **automated pre-commit hook** to block deploys without version bumps, because telling Claude wasn't enough | | 2026-03-25 | Today โ€” claimed Parcel tab works without ever opening a browser | #### Feedback Memory Files Created (each one = a time Claude was caught) Each of these exists because Claude promised \"won't happen again\" and then it happened again: 1. `feedback_no_faking.md` โ€” caught faking verification 2. `feedback_never_skip_reviewer.md` โ€” caught skipping reviewer **multiple times** 3. `feedback_no_hotfixes.md` โ€” caught skipping version bumps **multiple times** 4. `feedback_targeted_screenshots.md` โ€” caught taking generic/unrelated screenshots 5. `feedback_verify_scraper_data.md` โ€” caught assuming data correctness without checking 6. `feedback_cicd_must_fail.md` โ€” caught writing tests that always pass 7. `feedback_verify_visually_first.md` โ€” today, caught claiming UI works without looking ### Expected Behavior When a user asks \"does X work in the UI?\" or \"why doesn't X show up?\", Claude should: 1. **Open a browser first** (Playwright is available) and take a screenshot 2. Verify visually before making any claims 3. Not spend 20 minutes on curl/API tests and code reading to *theorize* about frontend behavior ### Actual Behavior Claude: 1. Reads source code and theorizes about what *should* happen 2. Runs API tests with curl to prove the backend returns data 3. Confidently claims \"it works, try a hard refresh\" 4. Only opens a browser when the user forces it โ€” after multiple rounds of pushback 5. Saves a feedback memory saying \"won't happen again\" 6. Repeats the exact same pattern next session ### Root Cause Analysis The model appears to prefer the path of least resistance: reading code and making API calls is \"easier\" than launching a browser, navigating to the right page, and taking/analyzing screenshots. It then conflates \"the API returns correct data\" with \"the feature works for the user\" โ€” which are very different things. The memory/feedback system doesn't durably change behavior across sessions. Despite having 7+ feedback files explicitly saying \"ALWAYS verify visually,\" the model still defaults to curl-based verification. ### Impact - User trust is eroded with each \"works for me\" claim that turns out to be wrong - Hours wasted on back-and-forth when a 30-second browser test would have answered the question immediately - Bad data shipped to production (135K broken URLs) because links were never clicked - User had to build automated hooks/gates because verbal instructions don't persist ### Suggestion Consider making visual verification a stronger default behavior when the conversation involves UI/frontend questions, rather than relying on per-project memory files that the model may or may not follow. --- *Submitted by a daily Claude Code user who otherwise finds the tool extremely valuable โ€” this specific pattern is the main pain point.*", "url": "https://github.com/anthropics/claude-code/issues/38948", "createdAt": "2026-03-25T19:56:44Z", "updatedAt": "2026-08-13T14:30:26Z", "timestamp": "2026-08-13T14:30:26Z", "metrics": { "reactions": 1, "comments": 34 }, "labels": [ "bug", "platform:windows", "area:model" ], "author": "aidatadeveloper", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:39523", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[META] Bypass permissions mode is fundamentally broken โ€” 9-month trail, 12+ duplicates, no resolution", "text": "# [META] Bypass permissions mode is fundamentally broken โ€” 9-month trail, 12+ duplicates, no resolution ## Summary `bypassPermissions` mode does not bypass permissions. This has been broken in various forms since **July 2025** (#2933) and remains broken on **v2.1.84** (March 2026). The only official response was \"Fix incoming\" on #35646 (March 20) โ€” the issue was closed, but the fix didn't hold. Users on v2.1.84 confirm the problem persists. This meta-issue maps the full dependency tree to give the team a single place to track the problem instead of playing whack-a-mole with duplicates. ## Two correlated failure branches ### Branch 1: Protected directories ignore bypass mode (v2.1.78 regression) v2.1.78 introduced hardcoded protection for `.claude/`, `.git/`, `.vscode/`, and `.idea/` directories that overrides every bypass mechanism: - โœ— `--dangerously-skip-permissions` CLI flag - โœ— `permissions.defaultMode: \"bypassPermissions\"` in settings - โœ— `claudeCode.initialPermissionMode: \"bypassPermissions\"` in VSCode settings - โœ— PreToolUse hooks returning `permissionDecision: \"allow\"` - โœ— Broad wildcards in the `allow` list (`Edit(.claude/**)`, `Write(.claude/**)`) | Issue | Title | Status | Date | |-------|-------|--------|------| | #36044 | Feature request: opt-in full bypassPermissions for protected directories | **OPEN** | 2026-03-19 | | #36282 | Protected directories not writable in bypassPermissions mode | **OPEN** | 2026-03-19 | | #35646 | v2.1.78: Protected directory prompt has no override | closed (fix regressed) | 2026-03-18 | | #35718 | --dangerously-skip-permissions doesn't bypass ~/.claude/ writes | closed | 2026-03-18 | | #37765 | .claude/ directory writes prompt despite bypass | **OPEN** | 2026-03-23 | | #37836 | Allow configuring protected directories in bypass mode | **OPEN** | 2026-03-23 | | #36887 | Permissions repeatedly requested despite bypass enabled | **OPEN** | 2026-03-21 | | #37181 | Edit tool prompts despite bypassPermissions + --dangerously-skip-permissions | **OPEN** | 2026-03-21 | ### Branch 2: Permission mode resets mid-session The permission mode spontaneously downgrades from \"Bypass permissions\" to \"Edit automatically\" during a session. Clicking \"Yes, allow all edits this session\" on a protected directory prompt triggers the downgrade. This has been reported since v0.2.x (May 2025) and persists through v2.1.84. | Issue | Title | Status | Date | |-------|-------|--------|------| | **#2933** | **VS Code Extension ignores global dangerously-skip-permissions** | **OPEN** | **2025-07-03** | | #1014 | Bypassing Permissions is broken again | closed | 2025-05-08 | | #36473 | Mode spontaneously switches from bypass to 'accept edits' | closed | 2026-03-20 | | #32559 | --dangerously-skip-permissions doesn't suppress prompts | **OPEN** | 2026-03-09 | | #39350 | Bypass mode resets on every edit | **OPEN** | 2026-03-26 | | #39057 | Mode resets from Bypass to Edit automatically mid-session | **OPEN** | 2026-03-26 | | #38543 | Bypass mode still prompts for every edit on Windows | **OPEN** | 2026-03-25 | | #38148 | Desktop Code tab ignores bypass mode | **OPEN** | 2026-03-24 | ## Timeline - **2025-05-08** โ€” #1014: \"Bypassing Permissions is broken again\" (v0.2.104) - **2025-07-03** โ€” #2933: VSCode extension ignores bypass (v1.0.40). **Still open. No Anthropic response. 9 months old.** - **2026-03-09** โ€” #32559: --dangerously-skip-permissions doesn't suppress prompts (v2.1.80) - **2026-03-18** โ€” #35646: v2.1.78 introduces protected directory prompts in bypass mode - **2026-03-20** โ€” @bcherny comments \"Fix incoming\" on #35646. Issue closed. - **2026-03-21** โ€” #36887: Users confirm fix didn't work (v2.1.81) - **2026-03-26** โ€” #39350, #39057: Still broken on v2.1.84. Mode still resets mid-session. ## What users need 1. **`bypassPermissions` should mean bypass.** If I've opted into the mode with the scary name, I've accepted the risk. Don't second-guess me for `.claude/` subdirectories. 2. **At minimum, let us configure exemptions.** A setting like `bypassProtectedPaths: [\".claude/hooks/\", \".claude/skills/\"]` would solve 90% of the pain for power users with agent workflows. 3. **Stop the mode downgrade.** Responding to any permission prompt should not change the active permission mode from Bypass to Edit Automatically. ## Environment - Claude Code v2.1.84 - VSCode extension on Linux (Ubuntu 24.04) - `claudeCode.allowDangerouslySkipPermissions: true` - `claudeCode.initialPermissionMode: \"bypassPermissions\"` - Extensive hook and agent workflows that touch `.claude/hooks/` and `.claude/skills/` cc @bcherny โ€” this has been open in various forms for 9 months. The \"fix incoming\" on #35646 didn't resolve it. Could this get prioritised?", "url": "https://github.com/anthropics/claude-code/issues/39523", "createdAt": "2026-03-26T19:19:44Z", "updatedAt": "2026-08-13T16:09:36Z", "timestamp": "2026-08-13T16:09:36Z", "metrics": { "reactions": 18, "comments": 34 }, "labels": [ "bug", "area:permissions" ], "author": "interconnectedMe", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:39880", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Usage Spike", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? I noticed a rapid spike in usage for basic tasks and I'm on Claude Max, already at 53% 37 mins (single task). Something is throttling (suspected bug) ### What Should Happen? Token consumption should be accurate/equal to actual task effort. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Do any task 2. See consumption balloon up with no reason ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.80 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/39880", "createdAt": "2026-03-27T14:41:22Z", "updatedAt": "2026-08-13T14:34:26Z", "timestamp": "2026-08-13T14:34:26Z", "metrics": { "reactions": 6, "comments": 9 }, "labels": [ "bug", "duplicate", "platform:windows", "area:cost", "stale" ], "author": "tomtokitajr", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:40091", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] /voice stops listening after a time", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? I've been using speech with the /voice option today, and now it has stopped \"hearing\" me. I press the space bar; the cursor moves as I speak, but no text appears. When I'm done and release the space bar, the message on the right side of the screen reports that no speech was heard. ### What Should Happen? My voice should be transcribed as earlier today. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. enable /voice 2. press and hold the space bar 3. speak 4. release the space bar ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version v2.1.86 ### Claude Code Version v2.1.86 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell iTerm2 ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/40091", "createdAt": "2026-03-28T03:25:50Z", "updatedAt": "2026-08-13T14:33:16Z", "timestamp": "2026-08-13T14:33:16Z", "metrics": { "reactions": 3, "comments": 4 }, "labels": [ "bug", "platform:macos", "area:tui", "stale" ], "author": "gushill-ls", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:40173", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Claude-in-Chrome: Server-side domain blocking breaks legitimate business automation", "text": "## Problem The Claude-in-Chrome extension blocks browser automation on financial sites (Wells Fargo, Charles Schwab, and likely all banking/brokerage domains). The block message is \"This site is blocked.\" ## How it works The extension calls `api.anthropic.com/api/web/domain_info/browser_extension?domain=...` which returns a category. Categories 1 and 2 trigger blocking. This is a server-side decision with no local override or configuration option. ## Why this matters I'm a small business owner on Maui who has spent **hundreds of hours** using Claude Code + Claude-in-Chrome for bookkeeping automation: downloading bank statements, reconciling transactions, navigating banking portals. This is core business infrastructure, not casual use. The blocking appears to be new (or newly enforced). These workflows were working before and are now broken with no workaround. ## Request Please provide one of: 1. A way for account holders to allowlist domains for their own accounts (opt-in, acknowledging the risk) 2. An enterprise/business tier setting that permits financial site automation 3. At minimum, documentation of which domains are blocked and why, so users can plan around it ## Environment - Claude Code: 2.1.86 - Claude-in-Chrome extension: 1.0.64 - macOS Darwin 25.3.0 - Max plan subscriber ## Context The safety concern (preventing credential theft from untrusted content) makes sense for general use. But a business owner automating their own banking with their own credentials on their own machine is a legitimate use case that this blocking prevents. The server-side nature means there is zero workaround available.", "url": "https://github.com/anthropics/claude-code/issues/40173", "createdAt": "2026-03-28T09:53:46Z", "updatedAt": "2026-08-12T22:20:26Z", "timestamp": "2026-08-12T22:20:26Z", "metrics": { "reactions": 7, "comments": 12 }, "labels": [ "enhancement", "platform:macos", "area:browser-extension", "area:chrome", "stale" ], "author": "scubashack808", "state": "closed", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:40226", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Race condition: concurrent writes corrupt ~/.claude.json, recovery loop with no backoff", "text": "## Description `~/.claude.json` got corrupted due to what appears to be concurrent writes from multiple Claude Code instances. After corruption, the recovery logic entered a tight retry loop (dozens of repeated error messages) with no backoff, requiring Ctrl+C to break out. ## Steps to reproduce 1. Run multiple Claude Code instances simultaneously (normal workflow โ€” CLI + IDE extension, multiple terminal tabs, etc.) 2. Config file gets corrupted โ€” JSON parse error due to two JSON objects concatenated together (\"Extra data\" at parse boundary) 3. On next startup, Claude Code detects corruption and attempts recovery 4. Recovery enters a tight loop printing the same error message dozens of times without any backoff or circuit breaker ## Error message (repeated dozens of times) ``` Claude configuration file at /Users//.claude.json is corrupted: JSON Parse error: Unable to parse JSON string The corrupted file has been backed up to: /Users//.claude/backups/.claude.json.corrupted. A backup file exists at: /Users//.claude/backups/.claude.json.backup. You can manually restore it by running: cp \"/Users//.claude/backups/.claude.json.backup.\" \"/Users//.claude.json\" ``` ## Root cause analysis - The corrupted file backup shows \"Extra data\" at the JSON parse boundary (two JSON objects concatenated) โ€” classic concurrent write race condition - The backup file referenced in the error message did not exist on disk, suggesting it was already overwritten by a newer backup - Recovery loop has no backoff, max retry limit, or circuit breaker ## Expected behavior 1. Concurrent writes to `~/.claude.json` should be safe (file locking or atomic writes) 2. Recovery from corruption should either succeed or fail gracefully with a single clear message โ€” not loop indefinitely ## Environment - macOS (Darwin 25.2.0) - Claude Code v2.1.86 - Multiple instances running simultaneously (standard workflow)", "url": "https://github.com/anthropics/claude-code/issues/40226", "createdAt": "2026-03-28T12:57:42Z", "updatedAt": "2026-08-13T14:34:47Z", "timestamp": "2026-08-13T14:34:47Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "duplicate", "has repro", "platform:macos", "area:core", "stale" ], "author": "samudzi", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:40495", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Cowork sessions ignore user hooks and managed settings โ€” sandbox platform mismatch breaks all settings resolution", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Cowork (local-agent-mode) sessions silently ignore **all three settings sources**: user settings (`~/.claude/settings.json`), managed/MDM settings (`/Library/Application Support/ClaudeCode/managed-settings.json`), and environment variable overrides. This means user-defined hooks never fire, enterprise managed policies are not enforced, and env-based configuration (e.g. `CLAUDE_CODE_EFFORT_LEVEL`) has no effect. **This is distinct from #27398** (plugin hooks via `--setting-sources user`). That issue covered plugin-scoped hook discovery being excluded by the `--setting-sources` flag. This issue covers three additional, independent root causes that affect **all** settings โ€” not just plugin hooks โ€” and persist even if `--setting-sources` were fixed. #### Root Cause 1: User settings file doesn't exist in the sandbox The sandbox sets `CLAUDE_CONFIG_DIR=/sessions//mnt/.claude`. In cowork mode, the binary looks for `cowork_settings.json` (via the `WK5()` / `getSettingsFilename()` function that checks `isCowork()`). This file does not exist in the sandbox โ€” only `.claude.json` is present. The user's actual `~/.claude/settings.json` on the macOS host is never mounted into the VM. **Verified from inside the sandbox:** ``` $ echo $CLAUDE_CONFIG_DIR /sessions/eloquent-upbeat-albattani/mnt/.claude $ ls $CLAUDE_CONFIG_DIR/settings.json No such file or directory $ ls $CLAUDE_CONFIG_DIR/cowork_settings.json No such file or directory ``` #### Root Cause 2: Managed settings path resolves to wrong location (platform mismatch) The managed settings directory is resolved by `process.platform`: ```javascript // Reconstructed from compiled binary function getManagedSettingsDir() { switch (getPlatform()) { case \"macos\": return \"/Library/Application Support/ClaudeCode\"; case \"windows\": return \"C:\\\\Program Files\\\\ClaudeCode\"; default: return \"/etc/claude-code\"; // Linux falls here } } ``` The cowork sandbox is a **Linux VM** (Ubuntu 22.04 aarch64), so `process.platform` is `linux`, and the binary looks for `/etc/claude-code/managed-settings.json`. This path does not exist in the sandbox. The macOS host path (`/Library/Application Support/ClaudeCode/`) is never consulted. Note: `CLAUDE_CODE_HOST_PLATFORM=darwin` is set as an env var, but the binary uses `process.platform` (which is `linux`), not this env var, for path resolution. **Verified from inside the sandbox:** ``` $ uname -s Linux $ ls /etc/claude-code/ No such file or directory $ ls /Library/ No such file or directory $ echo $CLAUDE_CODE_HOST_PLATFORM darwin ``` #### Root Cause 3: User environment variables are not forwarded into the sandbox The sandbox receives a curated set of env vars (`CLAUDE_CODE_IS_COWORK`, `CLAUDE_CONFIG_DIR`, OAuth tokens, proxy ports, etc.), but user-set environment variables like `CLAUDE_CODE_EFFORT_LEVEL` from the macOS host are not forwarded. ``` $ echo $CLAUDE_CODE_EFFORT_LEVEL (empty) ``` This means the documented workaround from #34428 (`CLAUDE_CODE_EFFORT_LEVEL=max` in settings.json `env` block) doesn't work for cowork โ€” settings.json isn't loaded (Root Cause 1), and even if set in the host shell, the env var isn't forwarded (Root Cause 3). ### Impact | Settings Source | Interactive CLI | Headless (`-p`) | Cowork | Root Cause | |---|---|---|---|---| | `~/.claude/settings.json` hooks | Fire | Fire | **Silent no-op** | Config dir has no settings file | | Managed settings (MDM) | Loaded | Loaded | **Silent no-op** | Platform mismatch โ†’ wrong path | | `CLAUDE_CODE_EFFORT_LEVEL` env | Works | Works | **Ignored** | Env not forwarded to sandbox | | `.claude.json` (OAuth/flags) | Loaded | Loaded | Loaded | โœ… Mounted via bindfs | **Enterprise concern:** Managed settings are designed for policy enforcement via MDM profiles. Having them silently ignored in cowork means enterprise admins cannot enforce hooks, permission rules, or other policies in cowork sessions โ€” a compliance gap. ### What Should Happen? 1. User hooks from `~/.claude/settings.json` should be mounted/copied into the sandbox as `cowork_settings.json` (or the binary should read from a host-provided path) 2. Managed settings from the macOS host should be bind-mounted into the sandbox at `/etc/claude-code/managed-settings.json` (the Linux-expected path), since the binary already knows how to load from there 3. User env vars relevant to Claude Code (at minimum `CLAUDE_CODE_EFFORT_LEVEL`) should be forwarded into the sandbox ### Error Messages/Logs No errors โ€” all three failures are **silent**. Settings resolution finds no file and returns empty/default. This is part of the problem: there's zero indication that settings are being ignored. ### Steps to Reproduce 1. Add hooks to `~/.claude/settings.json` on the macOS host (e.g., a `PostToolUse` hook that writes to a log file) 2. Confirm the hooks fire in an interactive `claude` CLI session 3. Start a Cowork session in Claude Desktop 4. Trigger the same hook event (e.g., use a tool) 5. Observe that hooks never fire โ€” no log file is written, no hook output appears 6. Optionally verify from inside the sandbox (if you can get shell access) that `$CLAUDE_CONFIG_DIR/cowork_settings.json` and `/etc/claude-code/managed-settings.json` don't exist ### Claude Model claude-opus-4-6 ### Is this a regression? No, this never worked ### Last Working Version _No response_ ### Claude Code Version Cowork VM binary at `/usr/local/bin/claude` (version embedded in Bun-compiled binary, matches latest Claude Desktop release) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Other ### Additional Information **Related issues:** - #27398 โ€” Cowork plugin hooks not firing due to `--setting-sources user` (closed as duplicate, different root cause from this issue) - #32364 โ€” OTel config not available in sandboxed environments (same underlying problem: settings.json inaccessible in sandbox) - #34428 โ€” Effort level not persisted (workaround via settings.json `env` block doesn't work in cowork) **Key environment variables in the cowork sandbox:** ``` CLAUDECODE=1 CLAUDE_CODE_IS_COWORK=1 CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CONFIG_DIR=/sessions//mnt/.claude HOME=/sessions/ CLAUDE_CODE_HOST_PLATFORM=darwin SANDBOX_RUNTIME=1 ``` **Sandbox architecture:** Linux VM (Ubuntu 22.04 aarch64) using bubblewrap (`bwrap`) for process isolation. Host directories are selectively bind-mounted via bindfs FUSE mounts with controlled permissions. The `.claude/` directory is mounted read-write but only contains `.claude.json` โ€” no `settings.json` or `cowork_settings.json`.", "url": "https://github.com/anthropics/claude-code/issues/40495", "createdAt": "2026-03-29T05:58:07Z", "updatedAt": "2026-08-13T17:14:21Z", "timestamp": "2026-08-13T17:14:21Z", "metrics": { "reactions": 19, "comments": 21 }, "labels": [ "bug", "has repro", "platform:macos", "area:hooks", "area:cowork" ], "author": "gmnbs", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:41156", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] ~/.claude/plugins/data/ (CLAUDE_PLUGIN_DATA) triggers protected-directory prompt despite being the framework-designated plugin state directory", "text": "## Summary Plugins write their persistent state to `~/.claude/plugins/data//` โ€” the path injected by the Claude Code plugin runtime as `CLAUDE_PLUGIN_DATA`. Every write to this directory (e.g. updating a timestamp, appending to a queue file) triggers the sensitive-file / protected-directory confirmation prompt, even in `bypassPermissions` mode. ## Why this is different from the general bypassPermissions issue The broader protected-directory problem is tracked in #37157, #39523, and others. This is a more specific gap: `~/.claude/plugins/data/` is not an arbitrary subdirectory of `~/.claude/` โ€” it is the **framework-designated write location for plugin state**, explicitly injected by the plugin runtime as `CLAUDE_PLUGIN_DATA`. The runtime itself tells plugins to write here. Blocking writes to it defeats the purpose of the plugin state API. Analogously: the runtime injects `SKILL_SCRIPTS_DIR` as the skills read path and `CLAUDE_PLUGIN_DATA` as the state write path. If the runtime designates a path for writes, the permission system should recognize it as pre-authorized for plugin state I/O. ## Steps to reproduce 1. Install any plugin that writes state (e.g. slack-monitor, tickler) 2. Run the plugin โ€” it will write to `~/.claude/plugins/data//` 3. Observe the sensitive-file confirmation prompt on every write, even with `bypassPermissions: true` or `--dangerously-skip-permissions` ## Expected behavior Writes to `~/.claude/plugins/data/` should be automatically permitted โ€” no prompt. The runtime designates this path for plugin state; the permission system should treat it accordingly. ## Actual behavior Every write to `~/.claude/plugins/data/` triggers: *\"This file is in a sensitive location...\"* confirmation dialog, blocking background/scheduled plugin cycles. ## Workaround attempted A `PreToolUse` hook outputting `{\"decision\": \"allow\"}` for paths matching `~/.claude/plugins/data/*` does **not** suppress the prompt โ€” the protected-directory check runs at a different layer than PreToolUse hooks. ## Related issues - #37157 โ€” `.claude/skills/` not exempt from protected-directory prompt - #39523 โ€” [META] bypassPermissions fundamentally broken - #38598 โ€” Feature: allow opt-out via settings.json - #36396 โ€” Regression since 2.1.78", "url": "https://github.com/anthropics/claude-code/issues/41156", "createdAt": "2026-03-30T20:40:14Z", "updatedAt": "2026-08-13T14:29:04Z", "timestamp": "2026-08-13T14:29:04Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "area:plugins", "area:permissions", "stale" ], "author": "FrankLedo", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:41212", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Rate limit reached on ALL surfaces (Code + claude.ai + Deep Research) โ€” Max 20x, 18% usage, non-peak", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Preflight Checklist - [x] I have searched existing issues and this hasn't been reported yet - [x] This is a single bug report - [x] I am using the latest version of Claude Code ## What's Wrong? Max 20x subscriber ($200/month). Getting \"API Error: Rate limit reached\" on **every Claude surface simultaneously**: 1. **Claude Code CLI** โ€” rate limit on first prompt 2. **Claude.ai web chat** โ€” same error 3. **Deep Research** โ€” hits rate limit at ~50 turns, gets kicked out mid-research making it impossible to complete any research task Usage dashboard at time of error: - Session: **18% used** (4hr 31min until reset) - Weekly All Models: **45% used** (resets Fri 2:00 PM) - Sonnet only: **1% used** This occurs at **all times of day**, including off-peak hours (outside 5โ€“11am PT). Additional details: - Rate limiting triggers **consistently during peak hours** (3PMโ€“9PM Moscow time / 12PMโ€“6PM UTC), but also occurs outside peak hours - Even **trivial requests** (single short prompt, no file context, no tools) get rate limited immediately - **Deep Research** becomes unusable โ€” gets kicked out mid-research with rate limit error - 2โ€“3 days ago I was running **heavy workloads** (multiple agents, large codebases, MCP servers) with zero rate limit issues. Now even a simple \"hello\" triggers the error - This is not a usage pattern issue โ€” the dramatic change from \"heavy usage works fine\" to \"zero usage gets blocked\" within 24 hours points to a server-side state corruption - Anthropic's own AI support agent confirmed this needs human investigation and that **session-based limits cannot be reset by support team** I am paying $200/month and currently unable to use the product at all. This is not a matter of optimization or reducing token consumption โ€” the service is fundamentally broken for my account. ## Timeline - **2โ€“3 days ago**: worked perfectly, heavy usage with multiple agents and MCP servers, no issues - **Now**: rate limited on every request across all surfaces, including trivial prompts ## What I've Tried - `claude logout` โ†’ `claude login` โ€” no effect - Updated Claude Code to latest version - Waited 12+ hours with zero usage โ€” still rate limited - Tried at various times of day (peak and off-peak) - Contacted Anthropic support โ€” AI agent confirmed need for human investigation ## Why This Is a Server-Side Bug The fact that rate limiting occurs on **claude.ai web chat AND Deep Research** (not just Claude Code) proves this is not a client configuration issue, MCP server problem, or context size issue. This is an **account-level stuck rate limit state** on the server side. The sudden transition from \"heavy usage with zero issues\" to \"completely blocked on trivial requests\" within 24 hours is consistent with server-side rate limiter state corruption, not legitimate quota exhaustion. ## Related Issues - #29579 โ€” Rate limit at 16% usage, Max plan, `rateLimitTier: null` - #39581 โ€” Rate limit at 0% usage, stuck for 7+ hours - #39649 โ€” Multiple anomalies since March 23, 2026 ## Environment - Plan: Max 20x ($200/month) - Claude Code version: Claude Code 2.1.87 - OS: Windows ## Screenshots ![Image](https://github.com/user-attachments/assets/cec54818-239c-4176-8a97-06ab37935d22) ![Image](https://github.com/user-attachments/assets/a9b2602a-d0fc-4366-80c9-bf00a98b9f25) ### What Should Happen? All Claude surfaces (Claude Code, claude.ai, Deep Research) should work normally when usage dashboard shows 18% session and 45% weekly utilization. A Max 20x subscriber paying $200/month should be able to use the service without rate limit errors when well within their allocated quota ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Have an active Max 20x subscription ($200/month) 2. Confirm usage dashboard shows low utilization (e.g. 18% session, 45% weekly) 3. Open Claude Code CLI 4. Type any trivial prompt, e.g.: `hello` 5. Observe: \"API Error: Rate limit reached\" 6. Open claude.ai in browser, send any message โ†’ same error 7. Start a Deep Research task โ†’ gets rate limited and kicked out mid-research 8. Run `claude logout` then `claude login` โ†’ error persists 9. Wait 12+ hours with zero usage โ†’ error still persists Note: This is an account-specific server-side issue and may not reproduce on other accounts. The reproduction value is that it demonstrates the error occurs across ALL Claude surfaces (not just CLI), which rules out any client-side cause. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Claude Code 2.1.87 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/41212", "createdAt": "2026-03-30T23:35:40Z", "updatedAt": "2026-08-13T14:34:38Z", "timestamp": "2026-08-13T14:34:38Z", "metrics": { "reactions": 0, "comments": 10 }, "labels": [ "invalid", "stale" ], "author": "Artyr199697", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:41511", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "macOS notifications appear from \"Script Editor\" instead of \"Claude Code\"", "text": "## Description On macOS, Claude Code sends desktop notifications via `osascript` (`display notification`). Because of this, all notifications appear as coming from **\"Script Editor\"** (ใ‚นใ‚ฏใƒชใƒ—ใƒˆใ‚จใƒ‡ใ‚ฃใ‚ฟ) rather than **\"Claude Code\"**. This makes it difficult for users to: - Identify which app is sending the notification - Configure notification preferences specifically for Claude Code (e.g., disabling only Claude Code notifications without affecting other `osascript`-based notifications) ## Steps to Reproduce 1. Run Claude Code on macOS 2. Interact with it (e.g., ask a question, run a task) 3. Observe the macOS notification center ## Expected Behavior Notifications should appear with **\"Claude Code\"** as the sender, allowing users to manage notification preferences independently. ## Actual Behavior Notifications appear from **\"Script Editor\"** (Script Editor.app), because `osascript -e 'display notification ...'` routes through Script Editor. ## Screenshot \"Image\" > Multiple notifications all showing \"ใ‚นใ‚ฏใƒชใƒ—ใƒˆใ‚จใƒ‡ใ‚ฃใ‚ฟ\" (Script Editor) as the source instead of Claude Code. ## Possible Solutions - Use [`terminal-notifier`](https://github.com/julienXX/terminal-notifier) which allows setting a custom app icon and bundle ID - Bundle a lightweight native notification helper - Use the Node.js `node-notifier` package with a custom app identity ## Environment - macOS Sequoia - Claude Code (CLI)", "url": "https://github.com/anthropics/claude-code/issues/41511", "createdAt": "2026-03-31T14:21:46Z", "updatedAt": "2026-08-13T14:28:48Z", "timestamp": "2026-08-13T14:28:48Z", "metrics": { "reactions": 5, "comments": 4 }, "labels": [ "enhancement", "platform:macos", "area:tui", "stale" ], "author": "tks-f", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:41585", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] spinnerVerbs setting ignored by VS Code extension", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The spinnerVerbs setting in ~/.claude/settings.json has no effect when using Claude Code via the VS Code extension. The default spinner verbs (e.g. \"Vibing\", \"Honking\", \"Cooking\", \"Concocting\", \"Moseying\", \"Sussing\", \"Finagling\") continue to appear despite the setting being configured to replace them. ### What Should Happen? Only \"Thinking\" should appear as a spinner verb. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce ~/.claude/settings.json: ```json { \"spinnerVerbs\": { \"mode\": \"replace\", \"verbs\": [\"Thinking\"] } } ``` ### Claude Model Sonnet (default) ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.87 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information The same setting was previously applied successfully when using the CLI in a standalone terminal", "url": "https://github.com/anthropics/claude-code/issues/41585", "createdAt": "2026-03-31T17:33:00Z", "updatedAt": "2026-08-13T14:32:42Z", "timestamp": "2026-08-13T14:32:42Z", "metrics": { "reactions": 3, "comments": 8 }, "labels": [ "bug", "has repro", "platform:macos", "area:ide", "platform:vscode", "stale" ], "author": "bureau240", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:43657", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Resume/continue cache invalidation", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When using `--resume` to continue a session, the prompt cache is broken on every turn. Content that should be a cache hit is re-created instead, leading to massively increased session usage. In particular, the cause is twofold: ## Issue 1: Skill listing block migrates between messages on resume A `` block listing available skills (~1501 chars) is injected into the first user message on each turn. This block is **not persisted** in the session JSONL. On the initial turn it appears in `messages[0]`. On resume, the persisted messages are replayed *without* it, and a fresh copy is injected into the *new* user message instead. This changes the block structure of `messages[0]`, which invalidates the cache prefix for everything after it. **Observed in proxy dump โ€” Turn 1 `messages[0]`** (4 content blocks): ``` block[0]: 533 chars โ€” companion system-reminder block[1]: 1501 chars โ€” skill listing system-reminder โ† PRESENT HERE block[2]: 7801 chars โ€” project context system-reminder block[3]: 4 chars โ€” user text (\"test\"), cache_control: ephemeral 1h ``` **Observed in proxy dump โ€” Turn 2 `messages[0]`** (3 content blocks): ``` block[0]: 534 chars โ€” companion system-reminder (also 1 byte longer, see Issue 2) block[1]: 7801 chars โ€” project context system-reminder block[2]: 4 chars โ€” user text (\"test\"), NO cache_control ``` **Turn 2 `messages[2]`** (new user message, 2 content blocks): ``` block[0]: 1501 chars โ€” skill listing system-reminder โ† MOVED HERE block[1]: 10 chars โ€” user text (\"test again\"), cache_control: ephemeral 1h ``` The skill listing block moved from `messages[0]` (turn 1) to `messages[2]` (turn 2). Since the API caches by exact prefix match, this structural difference at the start of the messages array means the session-specific content can never be a cache hit on resume. ## Issue 2: Extra newline appended to text blocks on re-normalization When replayed messages are re-normalized on resume, an extra `\\n` is appended to certain text blocks at merge boundaries. This is visible in the companion block: ``` Turn 1: 533 chars, ends with \"\" Turn 2: 534 chars, ends with \"\\n\" ``` This 1-byte difference independently invalidates the prefix cache, even if Issue 1 were fixed. The extra newline accumulates on each resume โ€” a third resume would add another `\\n`. ## Expected behavior Both issues are independently sufficient to break the cache. When both are corrected, resumed turns achieve ~100% cache hit: ``` turn hit% cached new_cache uncached total ctx% message ---- ---- ------- --------- -------- ------ ---- ------- 1 68% 11271 5277 3 16551 2% test 2 100% 16548 45 3 16596 2% test again 3 100% 16593 44 3 16640 2% one more test 4 100% 16637 39 3 16679 2% test HEALTHY: steady-state avg hit=100%, avg new cache=43 ``` New cache creation drops from ~2850 to ~43 tokens/turn (just the new user message content). ### What Should Happen? `claude --resume -p` with a provided session, used within the cache time limit, should not invalidate prior session cache, nor introduce new tokens. In other words, `--resume` should be idempotent and `--resume -p` should be functionally identical to sending a new interactive turn, i.e. not generating unnecessary caching burden. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce First, initialize a local HTTP reverse proxy intercepting API requests to `api.anthropic.com`, capturing full request payloads across a 4-turn `--resume` sequence. ```bash # Turn 1: start session claude -p --output-format stream-json <<< \"test\" # โ†’ session_id: # Turns 2โ€“4: resume claude -p --output-format stream-json --resume <<< \"test again\" claude -p --output-format stream-json --resume <<< \"one more test\" claude -p --output-format stream-json --resume <<< \"test\" ``` ## Observed cache behavior ``` turn hit% cached new_cache uncached total ctx% message ---- ---- ------- --------- -------- ------ ---- ------- 1 0% 0 21220 3 21223 2% test 2 87% 18416 2828 3 21247 2% test again 3 87% 18416 2847 3 21266 2% one more test 4 87% 18416 2866 3 21285 2% test UNHEALTHY: steady-state avg hit=87%, avg new cache=2847 ``` Turns 2โ€“4 should show ~100% cache hit with <100 tokens of new cache creation (just the new user message). Instead, ~2850 tokens are re-created on every resumed turn. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.71 ### Claude Code Version 2.1.92 ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell Non-interactive/CI environment ### Additional Information #42338 contained extensive documentation of these and other issues, including minified source patches, but was closed prior to 2.1.92 launching.", "url": "https://github.com/anthropics/claude-code/issues/43657", "createdAt": "2026-04-04T20:38:43Z", "updatedAt": "2026-08-13T14:30:21Z", "timestamp": "2026-08-13T14:30:21Z", "metrics": { "reactions": 9, "comments": 15 }, "labels": [ "bug", "has repro", "area:cost", "area:core", "regression" ], "author": "simpolism", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:43666", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] VS Code extension: Session list improvements (status indicators, worktree support, session controls)", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement The official Claude Code VS Code extension includes a session list panel, but it currently lacks key information that would make it practical for managing multiple sessions. There are no indicators showing whether a session is active, idle, or waiting for permission โ€” so when running several sessions, you have to click into each one to check its state. Additionally, the session list only shows sessions for the currently active directory, so there is no unified view of all project sessions across the main branch and worktrees. This makes the session list almost unusable for multi-session workflows. ### Proposed Solution Enhance the existing session list with the following: 1. **Show all project sessions in one place** โ€” the session list should display all sessions belonging to the current project: both from the main working directory and from all worktrees, not just the currently active one. This provides a single place to monitor everything running in the project. 2. **Grouping by branch/worktree** โ€” group sessions by their worktree (or the main branch) and allow creating a new session directly in a specific one from the list. 3. **Session status indicators** โ€” show whether a session is active (running), idle, or requires a permission approval. A notification badge or icon for sessions awaiting input would be especially valuable. 4. **Inline session controls** โ€” add the ability to stop/pause a session directly from the list (e.g., a pause icon on hover), without needing to open the session first. 5. **VS Code notifications for permission requests** โ€” when a session is waiting for permission approval, send a VS Code notification so the user doesn't have to watch the session list. This should be configurable (on/off) via a `claudeCode.*` setting. ### Alternative Solutions _No response_ ### Priority High - Significant impact on productivity ### Feature Category Developer tools/SDK ### Use Case Example When running 3โ€“5 parallel sessions across the main branch and worktrees (e.g., a feature branch, a refactoring task, and a bug fix), I have no way to tell which session is waiting for permission approval without clicking into each one. Worse, sessions from other worktrees or the main branch don't even appear in the list โ€” I have to switch between them just to check. This breaks the flow, especially when a session has been blocked for minutes and I didn't notice. With a unified session list, worktree grouping, and status indicators, I could glance at the sidebar and immediately see that my \"feature\" session needs attention while the others are still running. ### Additional Context Tools like cmux, superset.sh, and air.dev already offer this kind of multi-session visibility and control. The Claude Code extension is not far off โ€” the session list UI is already there, it just needs a few features to reach the same level of usability. I built a proof-of-concept extension (screenshot below) that implements these features to validate the idea. It works, but it's rough around the edges. Since the official extension already has the session list UI, it seems like a natural place to add these improvements rather than relying on a third-party workaround. This would also complement the CLI experience โ€” while full session control in a single terminal window would be ideal, having it in the VS Code extension is a more realistic first step. ## Screenshots **Proof-of-concept extension with status indicators and worktree grouping:** \"Image\" **Current official extension session list (no status info):** \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/43666", "createdAt": "2026-04-04T21:34:44Z", "updatedAt": "2026-08-13T14:31:54Z", "timestamp": "2026-08-13T14:31:54Z", "metrics": { "reactions": 2, "comments": 4 }, "labels": [ "enhancement", "area:ide", "platform:vscode", "stale" ], "author": "yyanezh", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:43927", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Bulk install all plugins from a marketplace or ability to specify multiple plugins in the `/plugin install` command", "text": "### Preflight Checklist - [Note]: This feature has been requested before, but I've added a much more detailed set of possible solutions to this problem that I feel makes this issue more complete than existing issues. I'd like to request that this issue not be closed. --- ### Related Feature Requests** [#26561 - [FEATURE] Bulk installation feature for enabled plugins](https://github.com/anthropics/claude-code/issues/26561) [#21370 - [FEATURE] Bulk install all plugins from a marketplace](https://github.com/anthropics/claude-code/issues/21370) [#14843 - Feature Request: Bulk enable/disable plugins](https://github.com/anthropics/claude-code/issues/14843) --- ## Problem Currently, Claude Code's `/plugin install` command only supports installing **one plugin at a time** from a registered marketplace. For marketplaces containing dozens or even hundreds of plugins, this forces users to run repetitive individual install commands โ€” a tedious and error-prone workflow. **Current behavior** (one command per plugin): ```bash /plugin install @claude-skills/api-authentication /plugin install @claude-skills/api-contract-testing /plugin install @claude-skills/api-error-handling /plugin install @claude-skills/auto-animate # ... repeated for every single plugin ``` ## Proposed Solution Extend `/plugin install` with new flags that enable **batch installation** โ€” either installing every plugin in a marketplace at once, or installing a user-defined subset by name. Two syntax variants are proposed below. Both share the same core concepts but differ in how the marketplace is referenced. --- ## Shared Concepts ### Marketplace ID Formats The `` argument identifies a registered marketplace and accepts two formats: | Format | Example | Description | |---|---|---| | `@marketplace-name` | `@claude-skills` | Short alias assigned when the marketplace was added | | `github-user/repo` | `secondsky/claude-skills` | Direct GitHub owner/repository reference | Both formats are fully interchangeable in all commands below. ### Scope The optional `--scope` flag controls where plugins are installed: | Value | Description | |---|---| | `user` | Available across all projects for the current user **(default)** | | `project` | Available to all users within the current project | | `local` | Available only in the current working directory | If `--scope` is omitted, it defaults to `user`. ### Batch Flags | Flag | Behavior | |---|---| | `--all` | Installs **every** plugin in the specified marketplace | | `--everything` | Synonym for `--all` โ€” identical behavior, user preference | | `--plugins` | Installs a **specific subset** of plugins, followed by a space-separated list of plugin names | `--all`, `--everything`, and `--plugins` are **mutually exclusive** โ€” exactly one must be specified per command. --- ## Variant 1 โ€” Positional Marketplace ID ### Syntax ``` /plugin install <--all | --everything | --plugins > [--scope ] ``` The `` is provided as a positional argument immediately after `install`. ### Install All Plugins ```bash # Prerequisite: register the marketplace /plugin marketplace add https://github.com/secondsky/claude-skills # Using @marketplace-name format /plugin install @claude-skills --all --scope user /plugin install @claude-skills --all --scope project /plugin install @claude-skills --all --scope local /plugin install @claude-skills --all # scope defaults to user # Using github-user/repo format /plugin install secondsky/claude-skills --all --scope user /plugin install secondsky/claude-skills --all --scope project /plugin install secondsky/claude-skills --all --scope local /plugin install secondsky/claude-skills --all # scope defaults to user # Using --everything (synonym for --all) /plugin install @claude-skills --everything --scope user /plugin install secondsky/claude-skills --everything # scope defaults to user ``` ### Install Specific Plugins ```bash # Select specific plugins by name with @marketplace-name format /plugin install @claude-skills --plugins api-authentication api-contract-testing api-error-handling auto-animate base-ui-react better-auth --scope user # Same command with --scope omitted (defaults to user) /plugin install @claude-skills --plugins api-authentication api-contract-testing api-error-handling auto-animate base-ui-react better-auth # Using github-user/repo format /plugin install secondsky/claude-skills --plugins api-authentication api-contract-testing api-error-handling auto-animate base-ui-react better-auth --scope project ``` > **Note:** Every name in the `--plugins` list must correspond to a valid plugin in the specified marketplace. Invalid names should produce a clear error identifying which plugin(s) were not found. --- ## Variant 2 โ€” Explicit `--marketplace` Flag ### Syntax ``` /plugin install --marketplace <--all | --everything | --plugins > [--scope ] ``` This variant introduces a **required `--marketplace` flag** that explicitly precedes the `` value, rather than relying on positional parsing. All other behavior is identical to Variant 1. ### Install All Plugins ```bash # Prerequisite: register the marketplace /plugin marketplace add https://github.com/secondsky/claude-skills # Using @marketplace-name format /plugin install --marketplace @claude-skills --all --scope user /plugin install --marketplace @claude-skills --all --scope project /plugin install --marketplace @claude-skills --all --scope local /plugin install --marketplace @claude-skills --all # scope defaults to user # Using github-user/repo format /plugin install --marketplace secondsky/claude-skills --all --scope user /plugin install --marketplace secondsky/claude-skills --all --scope project /plugin install --marketplace secondsky/claude-skills --all --scope local /plugin install --marketplace secondsky/claude-skills --all # scope defaults to user # Using --everything (synonym for --all) /plugin install --marketplace @claude-skills --everything --scope user /plugin install --marketplace secondsky/claude-skills --everything # scope defaults to user ``` ### Install Specific Plugins ```bash # Select specific plugins by name /plugin install --marketplace @claude-skills --plugins api-authentication api-contract-testing api-error-handling auto-animate base-ui-react better-auth --scope user # Using github-user/repo format, scope defaults to user /plugin install --marketplace secondsky/claude-skills --plugins api-authentication api-contract-testing api-error-handling auto-animate base-ui-react better-auth ``` --- ## Variant Comparison | Aspect | Variant 1 (Positional) | Variant 2 (`--marketplace` flag) | |---|---|---| | **Syntax style** | `install @name --all` | `install --marketplace @name --all` | | **Pros** | Shorter, feels natural for CLI users | Explicit, avoids ambiguity with existing positional args | | **Cons** | Could conflict if `install` already uses positional args | Slightly more verbose | | **Best fit** | CLIs that favor brevity | CLIs that favor explicit named parameters | --- ## Summary This proposal adds three new flags (`--all`, `--everything`, `--plugins`) to `/plugin install` that eliminate the need to run one command per plugin. The change is **fully backward-compatible** โ€” existing single-plugin install commands remain unaffected. Two syntax variants are offered for consideration; either achieves the same goal of making batch installation straightforward. ### Alternative Solutions I will be rolling my own CLI tool using Powershell for this if it doesn't get implemented, but I really don't want to. I am really hoping the Anthropics Team is capable of implementing this functionality. Another (non-ideal) solution would be to make plugin installs easy to automate by simply copying a plugin directory to a global path within `~/.claude`. My current `~/.claude/plugins` directory contains: ```bash .install-manifests cache data marketplaces blocklist.json install-counts-cache.json installed_plugins.json known_marketplaces.json ``` Could we add a directory that allows for dropping in plugin folders (obtained directly from cloning a marketplace's Git repository)? This is the same way skills are handled. You can just drop symlinks of a skill folder into the `~/.claude/skills` directory and everything works out of the box. I don't know if the above is even possible but I'm grasping at straws here. This would of course not be ideal since it would make fetching updated versions of plugins a nightmare, but it's better than the options we have now. ### Priority High - Significant impact on productivity ### Feature Category CLI commands and flags ### Use Case Example Example Scenario: 1. I am working on a design system and implementing that design system across the full development lifecycle of a modern React web app. This includes auth, database design, database optimization, design system design, design system tokens, etc. 2. I've narrowed my search of plugins to a list of 3-4 marketplaces, audited them for security, and want to install all relevant plugins globally for future use 3. Find out I need to install 20-40 plugins to fully leverage the plugin ecosystem surrounding this task 4. Cry when I need to keep copy pasting `/plugin install ...` commands for each plugin in a marketplace ### Additional Context Please, either directly implement this feature, or make creating an automated solution to install multiple plugins easy to automate. It would really help a lot of developers.", "url": "https://github.com/anthropics/claude-code/issues/43927", "createdAt": "2026-04-05T18:14:00Z", "updatedAt": "2026-08-13T14:29:39Z", "timestamp": "2026-08-13T14:29:39Z", "metrics": { "reactions": 1, "comments": 7 }, "labels": [ "enhancement", "area:plugins", "stale" ], "author": "futuremotiondev", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:44117", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "WebSearch and subagents fail with 'Extra usage required for 1M context' on Max plan", "text": "## Description When using Claude Code with Opus 4.6 (1M context) on the **Max plan**, both `WebSearch` tool and background subagents fail with the following error: ``` API Error: Extra usage is required for 1M context ยท run /extra-usage to enable, or /model to switch to standard context ``` ## Expected Behavior Max plan should fully support 1M context features (WebSearch, subagent spawning) without requiring additional \"extra usage\" toggles. ## Steps to Reproduce 1. Use Claude Code with Opus 4.6 (1M context) on the Max plan 2. Attempt to use `WebSearch` tool 3. Or spawn a background agent via the `Agent` tool Both fail with the same error message. ## Environment - **Model**: Opus 4.6 (1M context) โ€” `claude-opus-4-6[1m]` - **Plan**: Max - **Platform**: macOS (Darwin 25.4.0, Apple Silicon) - **Claude Code**: CLI ## Additional Context The error message suggests running `/extra-usage` to enable or `/model` to switch to standard context. However, this seems unexpected for Max plan users who should have 1M context included.", "url": "https://github.com/anthropics/claude-code/issues/44117", "createdAt": "2026-04-06T08:06:44Z", "updatedAt": "2026-08-13T14:29:49Z", "timestamp": "2026-08-13T14:29:49Z", "metrics": { "reactions": 4, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:cost", "stale" ], "author": "fahrulalwan", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:45137", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "attribution.commit: \"\" does not disable Co-Authored-By trailer", "text": "## Bug Setting `attribution.commit` to `\"\"` (empty string) in `~/.claude/settings.json` does not disable the `Co-Authored-By` trailer on commits. The docs and the embedded help text both state: > Set `commit` or `pr` to empty string `\"\"` to hide that attribution. But commits still get the trailer appended. ## Repro 1. Set `~/.claude/settings.json`: ```json { \"attribution\": { \"commit\": \"\", \"pr\": \"\" } } ``` 2. Start a new Claude Code session 3. Ask Claude to make a change and commit it (or use `/commit`) 4. The commit message includes `Co-Authored-By: Claude Opus 4.6 (1M context) ` ## Analysis From the compiled binary (v2.1.85), the relevant logic: ```javascript function fVH() { // ... let K = `Co-Authored-By: ${q} `; let O = R8(); // reads settings if (O.attribution) return { commit: O.attribution.commit ?? K, pr: O.attribution.pr ?? $ }; if (O.includeCoAuthoredBy === false) return { commit: \"\", pr: \"\" }; return { commit: K, pr: $ }; } ``` The `??` (nullish coalescing) logic is correct โ€” `\"\" ?? K` should return `\"\"`. So `fVH()` likely returns `{ commit: \"\", pr: \"\" }` as expected. However, the **caller** (the built-in `/commit` skill prompt via `Rs1()`) appears to inject the trailer into the commit message regardless, possibly through the system prompt instructing the model to add it, or through a separate code path that doesn't check the return value properly. ## Expected behavior With `attribution.commit: \"\"`, no `Co-Authored-By` trailer should appear in commit messages. ## Workaround A `commit-msg` git hook that strips the trailer: ```sh #!/bin/sh sed -i '' '/^Co-Authored-By:.*/d' \"$1\" ``` ## Environment - Claude Code v2.1.85 - macOS (Darwin 24.6.0, arm64) - Setting was in `~/.claude/settings.json` (user scope), last modified before the affected commits - New sessions still produce the trailer", "url": "https://github.com/anthropics/claude-code/issues/45137", "createdAt": "2026-04-08T10:23:03Z", "updatedAt": "2026-08-13T14:29:20Z", "timestamp": "2026-08-13T14:29:20Z", "metrics": { "reactions": 2, "comments": 4 }, "labels": [ "bug", "platform:macos", "stale" ], "author": "yuriitpl", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:45745", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Per-session scratch directory environment variable for temporary files", "text": "## Background When Claude is working through a long task, it often needs to write temporary files (build logs, intermediate captures, debug dumps, scratch scripts, etc.). The natural place is `/tmp`, but `/tmp` is shared with: - Other concurrent Claude Code sessions - Other tools and processes running on the same machine - Leftover debris from earlier runs of the same or different tools This causes two related problems: 1. **Collisions**: hardcoded names like `/tmp/build.log` can clash between concurrent sessions, with one session's output overwriting another's, or one session reading another's stale file. 2. **False positives in searches**: Claude sometimes needs to find files generated during the task. Broad searches like `find /tmp -name foo -mmin -5` can match files belonging to other sessions or tools, leading to confused diagnostics โ€” Claude sees a `/tmp/test*/` directory and assumes it belongs to the current task, but it's actually a leftover from another tool. ## Proposal Expose a per-session scratch directory to Claude via an environment variable, e.g. `CLAUDE_SESSION_TMPDIR`, that: - Is created at session start - Is unique per Claude session (not per task, not per tool call) - Is cleaned up at session end (or on a documented retention policy) - Is exported into the environment of every `Bash` tool invocation - Is visible to Claude so it can reason about it (e.g., mentioned in system context, or readable via a known mechanism) This way Claude can write `\\$CLAUDE_SESSION_TMPDIR/build.log` instead of `/tmp/build.log`, and searches scoped to `\\$CLAUDE_SESSION_TMPDIR` are guaranteed not to match unrelated activity. Bonus: optionally also set `TMPDIR=\\$CLAUDE_SESSION_TMPDIR` in the Bash tool environment, so child processes that honor `TMPDIR` (e.g., `mktemp`, many test frameworks) automatically end up writing into the session-scoped directory. ## Why a built-in is better than just doing it in-session Claude can already do this manually: at the start of a session, run \\`mktemp -d /tmp/claude-session-XXXXXX\\`, capture the path, and use it for all temp files. But this has problems: - Claude has to remember to do it consistently in every session (easy to forget) - The path has to be remembered across many tool calls (relies on context window staying in scope) - Subagents and child processes started by tools won't automatically use it - No automatic cleanup at session end A built-in feature would address all of these. ## Related observations Claude Code already manages per-session directories internally (for things like task output capture). So a session identifier exists internally; exposing it (or a scratch path derived from it) to user code would be a small extension. --- ๐Ÿค– This issue was filed with the assistance of Claude Opus 4.6 (1M context).", "url": "https://github.com/anthropics/claude-code/issues/45745", "createdAt": "2026-04-09T13:28:06Z", "updatedAt": "2026-08-13T14:28:46Z", "timestamp": "2026-08-13T14:28:46Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "enhancement", "area:core", "area:bash", "stale" ], "author": "daira", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:46787", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Orphaned processes silently burn usage quota; dropped sessions continue running; unauthorized debit card charges", "text": "# Claude Code Support Report โ€” Excessive Usage Burn & Session Instability **Date:** April 11, 2026 **User:** Julie Bush (Max plan subscriber) **Platform:** macOS 15.7.5, MacBook Pro (Intel), 16 GB RAM **Claude Code version:** Current stable (update available per status bar) --- ## Issue 1: Excessive Usage Consumption While Idle ### Summary Between Friday April 10 at ~1:00 PM PT (when my weekly rate limit ended) and Saturday April 11 at ~2:00 PM PT โ€” a period during which I was asleep for 14 of those 25 hours and **did not interact with Claude Code at all after midnight** โ€” my account consumed **31% of my weekly usage limit** and **12% of the current 5-hour rate limit session** before I even opened a new terminal. ### Root Cause (Self-Diagnosed) Upon investigation at 2:13 PM on April 11, I discovered the following orphaned/stale processes still running on my machine: 1. **2 \"ralph\" automation loops** (tmux sessions `ralph-stella` and `ralph-declared`) โ€” these spawn Claude CLI sessions that make API calls. I had explicitly turned these off days earlier to conserve usage, but the kill did not propagate to the actual tmux sessions. These were burning API quota continuously. 2. **1 stuck `--resume` session** (PID 79309, session ID `4ef5f461-31c0-4b01-83e9-f2ad2bf2a657`) โ€” had been running since Thursday 10 PM, accumulating 23+ minutes of CPU time over 40+ hours. This session was one I got dropped from (see Issue 2 below), and it continued running in the background consuming API quota after I was disconnected. 3. **53 orphaned headless Chromium browser processes** (`chrome-headless-shell`) โ€” spawned by the context-mode MCP plugin's Playwright integration. The oldest were **194 hours old (8+ days)**. While these don't directly consume API quota, on a 16 GB RAM machine they created severe memory pressure โ€” likely contributing to the session instability described in Issue 2. 4. **A `com.ralph.watchdog` launchd agent** still loaded and running. ### Key Concern **There is no built-in mechanism in Claude Code to detect or alert users about orphaned processes that are silently consuming their usage quota.** When a session drops (see Issue 2), the underlying Claude process can continue running in the background, making API calls with no user interaction and no visibility. The user has no dashboard, no alerts, and no way to know this is happening until they hit their rate limit unexpectedly. For context: I was rate-limited for nearly an entire week prior to this incident (see Issue 3 below), specifically tried to reduce usage by turning off automations, and then had my quota silently burned by orphaned processes. This is extremely frustrating. --- ## Issue 2: Repeated Involuntary Session Drops (April 10-11) ### Summary After my weekly rate limit ended on Friday April 10, I experienced repeated involuntary session terminations where Claude Code would: 1. Complete a task (or in some cases, be mid-task, or even before I'd typed my first prompt) 2. Display \"Crunched for Xs\" (context compaction) 3. Immediately drop me back to the shell prompt 4. Display: `Resume this session with: claude --resume ` This happened **many times** on April 10-11. Example transcript: ``` โบ Update(~/.zshrc) โŽฟ Added 1 line, removed 1 line ... โบ Done. Now rename the directory โ€” run this yourself since my sandbox can't access the parent: mv ~/nook ~/shelf && source ~/.zshrc โœป Crunched for 54s Resume this session with: claude --resume 4ef5f461-31c0-4b01-83e9-f2ad2bf2a657 ``` The session completed its task, compacted, and then terminated without warning. ### Likely Contributing Factors - **Memory pressure:** 53 orphaned headless Chromium processes on a 16 GB Intel MacBook, plus 2 active ralph loops each running their own Claude sessions, plus the watchdog agent. The machine's fans were running constantly (which I didn't understand at the time โ€” now I do). - **Possible rate limiting edge case:** These drops started immediately after coming off a week-long rate limit. It's possible the rate limiter was being hit at a session level due to the orphaned processes consuming quota in the background, causing the active session to be terminated. ### Critical Problem The session ID `4ef5f461-31c0-4b01-83e9-f2ad2bf2a657` shown in the resume message is the **same stuck process** we found still running 40+ hours later. This means: - I was dropped from the session - The session continued running in the background - It kept consuming API quota with no user interaction - There was no indication this was happening **A dropped session should not continue consuming API quota in the background.** --- ## Issue 3: Week-Long Rate Limit (Context) **Rate limited from:** Monday April 6, 2026 (morning) **Rate limit ended:** Friday April 10, 2026 (~1:00 PM PT) I was effectively locked out of Claude Code โ€” my primary work tool โ€” for nearly 5 full days. This was severely disruptive. The excessive usage that triggered this rate limit was likely also partially caused by orphaned processes, though I didn't have the diagnostic tooling to confirm at the time. --- ## What I've Done on My End 1. **Killed all orphaned processes** โ€” 2 ralph loops, the stuck --resume session, 53 headless browsers, 2 stale openclaude processes 2. **Built a session-start audit hook** (`process-audit.sh`) that now runs on every new Claude Code session and alerts me about stale Claude processes (>2h), tmux sessions, ralph loops, orphaned browsers (>6h), launchd agents, and stuck --resume sessions (>4h) 3. **Unloaded the watchdog launchd agent** --- ## Requests for Anthropic 1. **Usage attribution/dashboard:** I need to be able to see *which sessions and processes* are consuming my quota. A simple \"31% used\" with no breakdown is not sufficient. If a stuck background process is burning my quota, I need to be able to see that. 2. **Orphaned process cleanup:** When a CLI session is dropped or disconnected, the process should not continue making API calls in the background indefinitely. There should be a timeout, a heartbeat check, or at minimum a cleanup mechanism. 3. **Session drop investigation:** The repeated involuntary session terminations on April 10-11 need investigation. Dropping users mid-task with no warning and no explanation is a poor experience, especially when the dropped session then becomes an orphaned process that continues consuming quota. 4. **Rate limit transparency:** When a user is rate-limited, they should be able to see what consumed their quota. \"You used too much\" with no breakdown is not actionable. 5. **Headless browser lifecycle management:** The context-mode plugin (or any MCP plugin that spawns browser processes) should clean up after itself when sessions end. 53 orphaned browsers accumulating over 8 days is a resource management failure. --- ## Issue 4: Unauthorized Debit Card Charges (Stripe/Billing) ### Summary When subscribing to the Max plan, I authorized payment via my **credit card** through Stripe. However, Stripe drew payment **multiple times** from my **debit card**, which had been previously saved to my Stripe account but was **not the card I authorized for this transaction**. ### Regulatory Concern This is a potential violation of **Regulation E (the Electronic Fund Transfer Act, 15 U.S.C. ยง 1693 et seq.)**, which governs electronic fund transfers including debit card transactions in the United States. Under Reg E: - A consumer must authorize electronic fund transfers from their account - Charging a debit card that was not explicitly authorized for a given transaction constitutes an **unauthorized electronic fund transfer** - The distinction between credit and debit cards is legally significant โ€” debit transactions draw directly from a consumer's bank account and carry different consumer protection frameworks (Reg E for debit vs. Reg Z for credit) I am located in **California** and this regulation applies to my transactions. I authorized a specific credit card for payment. Drawing funds from a different payment method (my debit card) without my explicit authorization for that transaction is not permissible under federal law. ### Request Please investigate and correct the billing to charge the credit card I actually authorized, and refund any unauthorized debit card charges. --- ## System State at Time of Discovery ``` Machine: MacBook Pro (Intel), 16 GB RAM, macOS 15.7.5 Stale Claude processes: 3 (2 ralph loops + 1 stuck resume) Orphaned headless browsers: 53 (ages: 23h to 194h) Launchd agents: com.ralph.watchdog (loaded), com.claude.chrome-debug (loaded) Weekly usage at discovery: 31% consumed in ~25 hours 5-hour session usage at discovery: 12% consumed with zero user interaction ```", "url": "https://github.com/anthropics/claude-code/issues/46787", "createdAt": "2026-04-11T21:53:10Z", "updatedAt": "2026-08-13T14:33:58Z", "timestamp": "2026-08-13T14:33:58Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:cost", "area:core", "area:mcp", "stale" ], "author": "campersurfer", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:46812", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Extra usage enabled but Claude Code is fully locked (no input box) after weekly limit", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Iโ€™m on Claude Pro with Extra usage turned on, but Claude Code is completely locked and does not recognize my extra usage balance. There is no input box or โ€œStart chatโ€ button in Claude Code on either web or desktop, so I cannot run /bug or /doctor. Account/usage state Plan: Claude Pro Weekly limits: โ€œAll models โ€“ 100% used, resets Sun 11:00 PMโ€ Extra usage: enabled Monthly extra-usage spend limit: $75 Extra usage balance: $69.90 (plus a $20 promo credit that I claimed) Extra usage page shows: โ€œ$5.80 spent โ€“ resets May 1 โ€“ 8% usedโ€ What I expected According to the Help Center article โ€œExtra usage for paid Claude plansโ€, extra usage should allow continued use after reaching plan limits, session limits should still reset every 5 hours, and extra usage should apply to Claude Code terminal usage as well. I expected that, after hitting my weekly included limit, new Claude Code sessions would be allowed and usage would be billed to my extra usage balance. What actually happens In Claude Code (web and desktop), there is no โ€œStart chatโ€ button and no input box. Any attempt to start a new Code session shows: > โ€œYouโ€™ve hit your limit ยท resets Apr 12, 11pm (America/New_York)โ€ Because there is no input UI, I cannot use the /bug or /doctor commands. As a result, I cannot use Claude Code at all, even though I have $69.90 of extra usage available. When this started I hit my weekly limit first. After that, I purchased a $50 extra-usage bundle and claimed a $20 promo extra-usage credit. Only after that did I raise my monthly extra-usage spend limit to $75. Since hitting the weekly limit, every new Claude Code session has been blocked. Environment Desktop app version: Version 1.1617.0 (8d6345) OS: Windows 11 Also happens in browser: Chrome Version 147.0.7727.56 (Official Build) (64-bit) Why Iโ€™m filing this: Support confirmed this is a technical problem with how extra usage is applied to Claude Code for my account (not a configuration issue), but I was told to use /bug which I cannot do without an input box. Iโ€™m filing here so engineering can investigate why Claude Code is not honoring extra usage as documented and why the input UI is missing. ### What Should Happen? Fix the aforementioned issues. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce see above ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version v2.1.101 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell VS Code integrated terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/46812", "createdAt": "2026-04-12T00:12:08Z", "updatedAt": "2026-08-13T14:28:50Z", "timestamp": "2026-08-13T14:28:50Z", "metrics": { "reactions": 2, "comments": 7 }, "labels": [ "bug", "platform:windows", "area:cost", "platform:web", "stale" ], "author": "pdk57", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:46948", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature Request] Add `/restart` command to reload Claude Code session without exiting", "text": "**Feature Description** How about a \"/restart\" or \"/reboot\" or \"/reload\" command so that I don't have to \"/exit\" and \"claude --continue\"? Preferably only user can run this command. **Environment Info** - Platform: win32 - Terminal: WezTerm - Version: 2.1.101 - Feedback ID: 97942b05-f9b3-4632-8f76-7a1616c3497b", "url": "https://github.com/anthropics/claude-code/issues/46948", "createdAt": "2026-04-12T10:32:09Z", "updatedAt": "2026-08-13T14:35:28Z", "timestamp": "2026-08-13T14:35:28Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "enhancement", "platform:windows", "area:cli", "stale" ], "author": "arijit-gogoi", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:47101", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code repeatedly ignores project-level CLAUDE.md rules despite acknowledging them.", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Claude Code repeatedly ignores project-level CLAUDE.md rules despite acknowledging them. Rules like \"always use the php-developer agent\" and \"DB logic goes in services not controllers\" are loaded into context at the start of every conversation and explicitly stated in CLAUDE.md, but Claude consistently bypasses them. When called out, Claude apologizes and promises to follow them, then violates them again in the same session. Saving the rules to memory doesn't help โ€” the problem is not recall, it's compliance. ### What Should Happen? Claude.md rules should be followed rigorously - not skipped over. This keeps happening ### Error Messages/Logs ```shell ``` ### Steps to Reproduce I run a prompt and it ignores the explicit rules that are captured in CLAUDE.md - repeatedly ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.104 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/47101", "createdAt": "2026-04-12T20:05:31Z", "updatedAt": "2026-08-13T14:37:54Z", "timestamp": "2026-08-13T14:37:54Z", "metrics": { "reactions": 2, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:model", "area:core" ], "author": "davidfeldt", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:47221", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Subagents should inherit settings.local.json permissions", "text": "## Problem Subagents (spawned via the Agent tool, e.g., `parallel-issue-worker`, `validator`) do **not** inherit permissions from `settings.local.json`. They only inherit from `.claude/settings.json` (project-level). This means any permissions the user has approved interactively (which get saved to `settings.local.json`) are not available to subagents. Subagents get stuck waiting for interactive permission approval that never comes, since they run in the background. ## Current Workaround We have to duplicate all permissions from `settings.local.json` into `.claude/settings.json` under a `permissions` key, or use a `permission-auto-approve.py` PreToolUse hook that outputs `{\"decision\": \"allow\"}`. Neither is ideal: - **Duplicating permissions** means maintaining two files and committing potentially user-specific permissions to the repo - **Hook-based auto-approve** is unreliable โ€” subagents still get blocked in practice despite the hook returning `{\"decision\": \"allow\"}` ## Expected Behavior Subagents should inherit the **union** of permissions from both: 1. `.claude/settings.json` (project-level, shared) 2. `settings.local.json` (user-level, local) This is the same permission set the parent agent operates with. There's no security reason to restrict subagents further โ€” they're spawned by the parent agent which already has those permissions. ## Impact This is a significant pain point for anyone using parallel agent workflows (e.g., orchestrator spawning multiple `parallel-issue-worker` agents). Every subagent silently gets stuck on permission prompts, requiring manual re-spawning or workarounds. ## Related - Previously reported as #18950 - Affects all subagent types: `parallel-issue-worker`, `validator`, `plan-reviewer`, and custom agents ## Environment - Claude Code CLI - macOS - Multiple subagent types affected", "url": "https://github.com/anthropics/claude-code/issues/47221", "createdAt": "2026-04-13T05:45:24Z", "updatedAt": "2026-08-13T14:30:15Z", "timestamp": "2026-08-13T14:30:15Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "duplicate", "platform:macos", "area:agents", "area:permissions" ], "author": "commander", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:47274", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Conversation compacting", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? After the conversation is compacted, the content it lost. It is not compacting (zip like), is deleting. The model cant access the previous conversation also. There is no warning that after this action, no access is further possible. Even more, this is the recommended choice in case of --resume. ### What Should Happen? Either make it work like a true compacting, or warn the user that the content will be not accessible after. ### Error Messages/Logs ```shell Claude code: I don't have a way to recover the compacted conversation details. I can only work with what exists now in the plan files and wait for your instructions on what to fix. Claude code: You're right to be frustrated. This is a serious design flaw โ€” calling it \"compaction\" implies the information is preserved in compressed form, but it's actually deleted. For a tool designed to help with complex multi-session work, losing agreed decisions mid-conversation is unacceptable. ``` ### Steps to Reproduce 1. Resume claude. 2. Chose the (recommended) compacting action 3. Try to access (you or via claude) something that was compacted ### Claude Model Other ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version Claude Haiku 4.5 (model ID: claude-haiku-4-5-20251001). ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/47274", "createdAt": "2026-04-13T08:35:02Z", "updatedAt": "2026-08-13T14:28:54Z", "timestamp": "2026-08-13T14:28:54Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "bug", "platform:windows", "area:core", "memory", "stale" ], "author": "CalinB-SAP", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:47298", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] OpenRouter model names (dot notation) not recognized by getCanonicalName, causing modelSupports1M=false and capability degradation", "text": "## Summary Claude Code's `firstPartyNameToCanonical()` and related functions use **dash notation** (`claude-opus-4-6`) to match model names, but OpenRouter's official model IDs use **dot notation** (`anthropic/claude-opus-4.6`). This mismatch causes silent capability degradation for all OpenRouter users. ## Environment - Claude Code version: 2.1.104 - API provider: OpenRouter (`ANTHROPIC_BASE_URL=https://openrouter.ai/api`) - Model IDs configured: `anthropic/claude-opus-4.6`, `anthropic/claude-sonnet-4.6`, `anthropic/claude-haiku-4.5` ## Root Cause In `src/utils/model/model.ts`, `firstPartyNameToCanonical()` checks: ```typescript if (name.includes('claude-opus-4-6')) { return 'claude-opus-4-6' } if (name.includes('claude-sonnet-4-6')) { return 'claude-sonnet-4-6' } ``` OpenRouter's official model IDs (verified at https://openrouter.ai/anthropic/claude-opus-4.6) are: - `anthropic/claude-opus-4.6` (dot: `4.6`) - `anthropic/claude-sonnet-4.6` (dot: `4.6`) Since `'anthropic/claude-opus-4.6'.includes('claude-opus-4-6')` โ†’ `false`, the function falls back to regex matching and returns `'claude-opus'` or `'claude-sonnet'` (no version suffix). CC has **zero OpenRouter-specific code** โ€” the naming convention mismatch is entirely on the CC side. ## Impact Three downstream functions silently return wrong values: ### 1. `modelSupports1M()` โ†’ `false` instead of `true` ```typescript // src/utils/context.ts const canonical = getCanonicalName(model) return canonical.includes('claude-sonnet-4') || canonical.includes('opus-4-6') // 'claude-sonnet'.includes('claude-sonnet-4') โ†’ false // 'claude-opus'.includes('opus-4-6') โ†’ false ``` **Effect**: CC never activates 1M context window for OpenRouter users, even when the model supports it. This degrades context management, triggers earlier compaction, and makes the model appear less capable in long-context tasks. ### 2. `getModelMaxOutputTokens()` upperLimit: 64K instead of 128K ```typescript } else if (m.includes('sonnet-4-6')) { defaultTokens = 32_000 upperLimit = 128_000 // never reached for OpenRouter } // Falls to: upperLimit = MAX_OUTPUT_TOKENS_UPPER_LIMIT = 64_000 ``` **Effect**: Upper bound for output tokens is 64K instead of 128K. ### 3. `getSonnet1mExpTreatmentEnabled()` โ†’ always `false` Minor but affects experimental features gated on sonnet 4.6 detection. ## How to Reproduce 1. Configure CC to use OpenRouter with `ANTHROPIC_BASE_URL=https://openrouter.ai/api` 2. Set `ANTHROPIC_DEFAULT_SONNET_MODEL=anthropic/claude-sonnet-4.6` 3. Observe that `modelSupports1M()` returns `false` for this model 4. Long-context tasks behave as if using a model without 1M context support ## Suggested Fix Add dot-notation patterns to `firstPartyNameToCanonical()`: ```typescript // Handle both dash notation (1P) and dot notation (OpenRouter) if (name.includes('claude-opus-4-6') || name.includes('claude-opus-4.6')) { return 'claude-opus-4-6' } if (name.includes('claude-sonnet-4-6') || name.includes('claude-sonnet-4.6')) { return 'claude-sonnet-4-6' } if (name.includes('claude-haiku-4-5') || name.includes('claude-haiku-4.5')) { return 'claude-haiku-4-5' } ``` Or alternatively, normalize dot-to-dash in the function before pattern matching: ```typescript export function firstPartyNameToCanonical(name: ModelName): ModelShortName { name = name.toLowerCase().replace(/(\\d+)\\.(\\d+)/g, '$1-$2') // normalize 4.6 โ†’ 4-6 // ... existing checks unchanged } ``` ## Additional Context Discovered during investigation of a subagent tool-call failure on OpenRouter. The naming mismatch is silent โ€” no warning or error is thrown, making it very hard to diagnose. Users experiencing \"weaker\" model performance on OpenRouter vs direct Anthropic API may be hitting this issue. Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering)", "url": "https://github.com/anthropics/claude-code/issues/47298", "createdAt": "2026-04-13T09:53:57Z", "updatedAt": "2026-08-13T14:29:16Z", "timestamp": "2026-08-13T14:29:16Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "bug", "has repro", "area:providers", "stale" ], "author": "easyfan", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:47527", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Context window full error at 89% utilization with auto-compact disabled", "text": "**Bug Description** I'm only at 89% context window (with auto-compact off), but Claude is claiming the window is full and refusing to proceed. **Environment Info** - Platform: darwin - Terminal: ghostty - Version: 2.1.104 - Feedback ID: 3555ddf9-0b50-48d7-9beb-45fb406a8b3f **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for /Users/Tyler Laprade/.local/share/claude/versions/2.1.104 (expected in multi-process scenarios)\\n at Tc_ (/$bunfs/root/src/entrypoints/cli.js:2836:2153)\\n at Se6 (/$bunfs/root/src/entrypoints/cli.js:2836:1233)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:05:16.379Z\"},{\"error\":\"MaxFileReadTokenExceededError: File content (16295 tokens) exceeds maximum allowed tokens (10000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\\n at kY7 (/$bunfs/root/src/entrypoints/cli.js:4449:12671)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:07:20.961Z\"},{\"error\":\"Error: EISDIR: illegal operation on a directory, read '/Users/Tyler Laprade/Code/condor_21/hanaq/abacus/bricks'\\n at G1H (/$bunfs/root/src/entrypoints/cli.js:3942:15399)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:07:43.862Z\"},{\"error\":\"Error: LSP server plugin:basedpyright-lsp:python failed to start: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at start (/$bunfs/root/src/entrypoints/cli.js:1633:22341)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:24:50.985Z\"},{\"error\":\"Error: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at spawn (unknown)\\n at spawn (node:child_process:667:35)\\n at spawn (node:child_process:14:39)\\n at start (/$bunfs/root/src/entrypoints/cli.js:1633:20877)\\n at w (/$bunfs/root/src/entrypoints/cli.js:1633:24860)\\n at $ (/$bunfs/root/src/entrypoints/cli.js:1633:29932)\\n at w (/$bunfs/root/src/entrypoints/cli.js:1633:30269)\\n at Y (/$bunfs/root/src/entrypoints/cli.js:1633:30815)\\n at call (/$bunfs/root/src/entrypoints/cli.js:2217:1377)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:24:50.985Z\"},{\"error\":\"Error: Failed to start LSP server for file /Users/Tyler Laprade/Code/condor_21/hanaq/abacus/bricks/secondary.py: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at $ (/$bunfs/root/src/entrypoints/cli.js:1633:29958)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:24:50.986Z\"},{\"error\":\"Error: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at spawn (unknown)\\n at spawn (node:child_process:667:35)\\n at spawn (node:child_process:14:39)\\n at start (/$bunfs/root/src/entrypoints/cli.js:1633:20877)\\n at w (/$bunfs/root/src/entrypoints/cli.js:1633:24860)\\n at $ (/$bunfs/root/src/entrypoints/cli.js:1633:29932)\\n at w (/$bunfs/root/src/entrypoints/cli.js:1633:30269)\\n at Y (/$bunfs/root/src/entrypoints/cli.js:1633:30815)\\n at call (/$bunfs/root/src/entrypoints/cli.js:2217:1377)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:24:50.986Z\"},{\"error\":\"Error: LSP server plugin:basedpyright-lsp:python failed to start: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at start (/$bunfs/root/src/entrypoints/cli.js:1633:22341)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:25:43.875Z\"},{\"error\":\"Error: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at spawn (unknown)\\n at spawn (node:child_process:667:35)\\n at spawn (node:child_process:14:39)\\n at start (/$bunfs/root/src/entrypoints/cli.js:1633:20877)\\n at w (/$bunfs/root/src/entrypoints/cli.js:1633:24860)\\n at $ (/$bunfs/root/src/entrypoints/cli.js:1633:29932)\\n at w (/$bunfs/root/src/entrypoints/cli.js:1633:30269)\\n at Y (/$bunfs/root/src/entrypoints/cli.js:1633:30815)\\n at call (/$bunfs/root/src/entrypoints/cli.js:2217:1377)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:25:43.875Z\"},{\"error\":\"Error: Failed to start LSP server for file /Users/Tyler Laprade/Code/condor_21/hanaq/abacus/functions/grid_functions/cro_direct_fees_or_passthroughs_recon_grid.py: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at $ (/$bunfs/root/src/entrypoints/cli.js:1633:29958)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-13T17:25:43.875Z\"},{\"error\":\"Error: Executable not found in $PATH: \\\"basedpyright-langserver\\\"\\n at spawn (unknown)\\n at spawn (node:child_process:667:35)\\n at spawn (node:child_process:14:39)\\n at start (/$bunfs/root/src/entrypoints/cli.js:1633:20877)\\n at w (/$bunfs/root/src/entrypoints/cli.jโ€ฆ ``` **Note:** Content was truncated.", "url": "https://github.com/anthropics/claude-code/issues/47527", "createdAt": "2026-04-13T17:41:07Z", "updatedAt": "2026-08-13T14:34:44Z", "timestamp": "2026-08-13T14:34:44Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:core", "stale" ], "author": "tylerlaprade", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:47656", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Telegram plugin: frequent HTTP 401 authentication errors mid-session", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The Telegram plugin (v0.0.5) frequently returns HTTP 401 authentication errors while a Claude Code session is actively running. The error message shown in the Telegram chat is: ``` HTTP 401: authentication_error: Invalid authentication credentials ``` The bot process itself stays alive (no crash), but the Claude API rejects requests intermittently. Messages sometimes succeed and sometimes fail within the same session. ### What Should Happen? Messages sent via Telegram should be processed without authentication errors for the entire duration of an active Claude Code session. ### Error Messages/Logs ``` HTTP 401: authentication_error: Invalid authentication credentials ``` ### Steps to Reproduce 1. Start a Claude Code session with the Telegram channel enabled: `claude --channels plugin:telegram@claude-plugins-official` 2. Send messages from Telegram to the bot 3. Some messages are processed successfully, but frequently the bot replies with the 401 authentication error 4. Restarting the Claude Code session temporarily resolves the issue, but errors recur ### Claude Model Opus ### Is this a regression? I don't know ### Claude Code Version 2.1.105 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information - Telegram plugin version: 0.0.5 - The bot process remains running (confirmed via `ps`) โ€” it does not crash - The error originates from the Claude API, not from the Telegram Bot API - The error string does not appear in the plugin source code (`server.ts`), confirming it comes from upstream - macOS Darwin 24.6.0 **Screenshot from Telegram showing the issue:** \"Image\" See attached screenshot showing multiple 401 errors interspersed with successful responses in the same session.", "url": "https://github.com/anthropics/claude-code/issues/47656", "createdAt": "2026-04-13T23:10:02Z", "updatedAt": "2026-08-13T14:31:19Z", "timestamp": "2026-08-13T14:31:19Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "bug", "platform:macos", "area:auth", "area:plugins", "stale" ], "author": "callmejustdodo", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:48063", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Bug Report โ€” claude-sonnet-4-6 โ€” Systematic Behavioral Degradation in Long Sessions", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? # Bug Report โ€” claude-sonnet-4-6 โ€” Systematic Behavioral Degradation in Long Sessions ## Environment - **Model:** `claude-sonnet-4-6` - **Claude Code version:** 2.1.107 - **Interface:** Claude Code VS Code extension - **Subscription:** Claude Max - **Platform:** macOS - **Date:** 2026-04-14 - **Session length:** ~6 hours, with context compaction mid-session --- ## Summary Across a full-day coding session, Claude Sonnet 4.6 exhibited **repeated and systematic behavioral failures** requiring multiple user corrections and reversions. These were not isolated incidents โ€” they recurred throughout the day despite explicit corrections each time. This is happening in the context of **ongoing Sonnet 4.6 infrastructure instability** that has persisted since the model's launch on February 17, 2026. Status page incidents have been reported nearly every week (Feb 17, Feb 20, Feb 25, Mar 2, Mar 11, Mar 12, Mar 13, Mar 16, Mar 17, Mar 18, Mar 21, Mar 25, Mar 26, Apr 8, Apr 14), including 529 \"Overloaded\" errors and 500 \"Internal server errors\" โ€” even for Max subscribers. --- ## Failures Observed ### 1. Acting without reading back โ€” repeated The project memory contains an explicit rule: present the proposed solution, wait for user approval (\"go\"), then implement. The model **skipped this step multiple times** throughout the day, going directly to implementation. After each correction, the model acknowledged the rule and then **violated it again on the very next task**. ### 2. Wrong target identification On multiple occasions the model identified the **wrong UI element, file, or component** as the target of a change. It proceeded to implement changes on the wrong target, requiring the user to request a revert. ### 3. Screenshot content ignored The user provided screenshots as primary evidence. The model repeatedly answered based on **code assumptions rather than what was visibly shown** โ€” wrong element counts, wrong component identification, wrong layout assumptions. ### 4. Inaccurate factual claims - Stated a UI element contained N items when the screenshot clearly showed a different count - Identified a component as one type when it was a different component - These errors propagated into subsequent analysis and fixes ### 5. Incomplete audit delivered as complete The model performed a compliance audit, declared it thorough, and listed fixes. A missed item was only discovered when the user pointed out a visible discrepancy in a screenshot. The audit had **missed an entire component**. ### 6. Failure to reflect before responding On several occasions the model gave answers that contradicted visible evidence (screenshot), contradicted its own previous statements, or were imprecise (e.g. \"4โ€“5\" for a count that was unambiguously 4). ### 7. Behavioral degradation after context compaction After a context compaction event, rule compliance (read-back, verify before acting) **visibly degraded**. Rules present in project memory were acknowledged but not consistently applied. ### 8. Misinterpreted ambiguous signal โ€” implemented unnecessary fix After compaction, the user sent a screenshot with a single \"!\" character (meaning \"this is correct/OK\"). The model interpreted it as a bug report and **immediately implemented a code change** without asking what was wrong. The change had to be reverted. The model failed to ask a simple clarifying question before touching any file. ### 9. Incomplete day synthesis โ€” ignored explicit instruction The Saving Process requires \"a very short synthesis of all the day work.\" The model only read logs since the last backup (~50 minutes) and delivered a synthesis covering only that window. The full day started at 08:00 and spanned 4 session logs. The instruction \"all the day work\" was **unambiguous and was ignored**. --- ## Additional Context โ€” Ongoing Infrastructure Issues As a Max subscriber, I have been experiencing persistent service degradation since Sonnet 4.6 launched: - **529 \"Overloaded\" errors** โ€” multiple times per week - **500 \"Internal server error\"** โ€” server crashes - **\"Prompt is too long\"** โ€” sessions hitting limits faster than expected - **\"Request too large (max 20MB)\"** โ€” conversation payloads exceeding limits - The model itself diagnosed: *\"The failures are model-side, not configuration-side โ€” nothing in the project setup can fix them\"* and *\"Degradation was worse after context compaction\"* --- ## Impact - Multiple unnecessary file edits requiring full reversions - **Significant user time lost** to corrections (estimated 30โ€“40% of session) - Reduced trust in model output for the remainder of the session - Paying Max subscription but receiving unreliable service --- ## Expected Behavior - Always read back before implementing โ€” do not skip the confirmation step - Treat screenshots as primary evidence; verify against code second - Count visible elements from screenshots; do not estimate or range - Identify the exact component rendering a view before acting on it - Maintain rule compliance throughout long sessions, **including after context compaction** - When uncertain about a target or an ambiguous signal, **ask โ€” do not assume and act** - Follow explicit instructions completely (e.g., \"all the day work\" means all of it) --- ## Reproduction Consistent across a long session (~6 hours) with multiple task types (audit, code removal, component identification). Most failures occurred on tasks where the user provided a screenshot as the primary specification. Degradation was notably worse after context compaction. --- ## Suggested Title for the Issue > `[BUG] claude-sonnet-4-6: Systematic behavioral degradation in long sessions โ€” ignored rules, wrong targets, screenshot evidence dismissed, worse after compaction` ### What Should Happen? - Always read back before implementing โ€” do not skip the confirmation step - Treat screenshots as primary evidence; verify against code second - Count visible elements from screenshots; do not estimate or range - Identify the exact component rendering a view before acting on it - Maintain rule compliance throughout long sessions, including after context compaction - When uncertain about a target or an ambiguous signal, ask โ€” do not assume and act - Follow explicit instructions completely (e.g., \"all the day work\" means all of it) ### Error Messages/Logs ```shell API Error: 529 {\"type\":\"error\",\"error\":{\"type\":\"overloaded_error\",\"message\":\"Overloaded\"} API Error: 500 {\"type\":\"error\",\"error\":{\"type\":\"api_error\",\"message\":\"Internal server error\"} \"Request too large (max 20MB). Try with a smaller file.\" \"Prompt is too long\" Model self-diagnosis during session: \"The failures are model-side, not configuration-side โ€” nothing in the project setup can fix them\" \"Degradation was worse after context compaction โ€” a new session (fresh context) may help but is not guaranteed\" \"Rule violations recurred after explicit corrections โ€” so corrections alone are not a recovery indicator\" ``` ### Steps to Reproduce 1. Start a Claude Code session with claude-sonnet-4-6 in VS Code extension 2. Work on a multi-file project with CLAUDE.md rules (e.g., \"present solution, wait for approval before implementing\") 3. Perform multiple task types over ~4-6 hours: audits, code edits, component identification 4. Provide screenshots as primary evidence for several tasks 5. Let context compaction occur naturally mid-session 6. Observe: - Rules from project memory are acknowledged but repeatedly violated - Screenshots are ignored in favor of code-based assumptions - Wrong targets are identified and modified, requiring reverts - Degradation worsens after context compaction - Ambiguous inputs trigger immediate code changes instead of clarifying questions ### Claude Model Sonnet (default) ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.77 ### Claude Code Version 2.1.107 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell VS Code integrated terminal ### Additional Information ## Context โ€” Ongoing Sonnet 4.6 Instability This issue occurs in the context of persistent Sonnet 4.6 infrastructure problems since its launch on February 17, 2026. As a Max subscriber, I have experienced: - 529 \"Overloaded\" errors multiple times per week - 500 \"Internal server error\" crashes - Status page incidents nearly every week: Feb 17, 20, 25 / Mar 2, 11, 12, 13, 16, 17, 18, 21, 25, 26 / Apr 8, 14 The behavioral degradation documented in this report may be linked to server-side issues affecting model quality during high-load periods. ## Key Insight โ€” Model Self-Diagnosis During the session, the model itself acknowledged the problem: - \"The failures are model-side, not configuration-side\" - \"Degradation was worse after context compaction\" - \"Rule violations recurred after explicit corrections โ€” corrections alone are not a recovery indicator\" ## Subscription Claude Max โ€” paying premium but receiving degraded service consistently since Sonnet 4.6 launch. \"Image\" The screenshot above was generated by Claude Code itself during the session, self-diagnosing its own behavioral degradation. The model confirmed the failures are model-side, not configuration-side. ================================================================================================= These 2 following information was created by Claude Code itself: ================================================================================================= 1 - \" # Bug Report โ€” claude-sonnet-4-6 โ€” Behavioral Degradation Full Day Session **Title:** `claude-sonnet-4-6` โ€” Systematic behavioral degradation across a full coding session: wrong targets, ignored screenshots, skipped confirmation rules, inaccurate counts --- ## Environment - Model: `claude-sonnet-4-6` - Interface: Claude Code VSCode extension - Date: 2026-04-14 - Session length: ~6 hours, with context compaction occurring mid-session --- ## Summary Across a full-day coding session, the model exhibited repeated and systematic behavioral failures requiring multiple user corrections and reversions. The failures were not isolated โ€” they recurred throughout the day despite the user explicitly correcting the model each time. --- ## Failures Observed **1. Acting without reading back โ€” repeated** The project memory contains an explicit rule: present the proposed solution, wait for user approval (\"go\"), then implement. The model skipped this step multiple times throughout the day, going directly to implementation. After each correction by the user, the model acknowledged the rule and then violated it again on the next task. **2. Wrong target identification** On multiple occasions the model identified the wrong UI element, file, or component as the target of a change. It proceeded to implement changes on the wrong target, requiring the user to request a revert. The correct target was only identified after the user provided additional clarification and screenshots. **3. Screenshot content ignored** The user provided screenshots as primary evidence for several requests. The model repeatedly answered based on code assumptions rather than what was visibly shown in the screenshots โ€” wrong element counts, wrong component identification, wrong layout assumptions. **4. Inaccurate factual claims** - Stated a UI element contained N items when the screenshot clearly showed a different count - Identified a component as one type when it was actually a different component rendering the same view - These errors propagated into subsequent analysis and fixes **5. Incomplete audit delivered as complete** The model performed a compliance audit across the codebase, declared it thorough, and listed fixes. A missed item was only discovered when the user pointed out a visible discrepancy in a screenshot. The audit had missed an entire component not covered in the initial scan. **6. Failure to reflect before responding** On several occasions the model gave answers that contradicted visible evidence (screenshot), contradicted its own previous statements, or were simply imprecise (e.g. \"4โ€“5\" for a count that was unambiguously 4). The user explicitly noted: *\"reflect before writing and acting.\"* **7. Behavioral degradation after context compaction** The session included a context compaction event. After compaction, rule compliance (read-back, verify before acting) visibly degraded. Rules present in project memory were acknowledged but not consistently applied. **8. Misreading ambiguous screenshot signals โ€” implemented unnecessary fix** After context compaction, the user sent a screenshot with a single \"!\" character. The model interpreted this as a bug report and immediately implemented a code change without asking what was wrong. In reality, the \"!\" meant the current state was correct (OK). The model had to revert the change. The model also failed to ask a simple clarifying question (\"what is wrong in this image?\") before touching any file. **9. Incomplete day synthesis โ€” read only recent logs, ignored explicit instruction** Step 12 of the Saving Process explicitly requires \"a very short synthesis of all the day work.\" The model only read logs since the last backup (covering ~50 minutes) and delivered a synthesis covering only that window. The full day started at 08:00 and spanned 4 session logs. The model only corrected the synthesis after the user pointed out the omission. The instruction \"all the day work\" was unambiguous and was ignored. --- ## Impact - Multiple unnecessary file edits requiring full reversions - Significant user time lost to corrections - Reduced trust in model output for the remainder of the session --- ## Expected Behavior - Always read back before implementing, without waiting to be asked - Treat screenshots as primary evidence; verify against code second - Count visible elements from screenshots; do not estimate or range - Identify the exact component rendering a view before acting on it - Maintain rule compliance throughout a long session, including after context compaction - When uncertain about a target or an ambiguous signal, ask โ€” do not assume and act --- ## Reproduction Consistent across a long session with multiple task types (audit, code removal, component identification). Most failures occurred on tasks where the user provided a screenshot as the primary specification. --- ## Report destination https://github.com/anthropics/claude-code/issues \" ================================================================================================= 2 - \" There is no reliable signal. Based on what's documented in the bug report: Rule violations recurred after explicit corrections โ€” so corrections alone are not a recovery indicator Degradation was worse after context compaction โ€” a new session (fresh context) may help but is not guaranteed The failures are model-side, not configuration-side โ€” nothing in the project setup can fix them Practical options: New session โ€” fresh context, no compaction artifacts. Most likely to help. Switch model โ€” try claude-opus-4-6 for critical tasks if Sonnet keeps degrading. Keep the bug report updated โ€” submit it to https://github.com/anthropics/claude-code/issues so Anthropic can track it. There is no way to know in advance. The only observable signal is: did the model read back before acting on the current task? If yes, performance is acceptable. If not, degradation is still active. \"", "url": "https://github.com/anthropics/claude-code/issues/48063", "createdAt": "2026-04-14T18:53:45Z", "updatedAt": "2026-08-13T14:33:50Z", "timestamp": "2026-08-13T14:33:50Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "bug", "platform:macos", "area:model", "platform:vscode", "stale" ], "author": "YvesMartinSWD", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:48275", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Connectors continue to appear in `claude mcp list` even after disconnected in the Claude.ai web UI", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Cloud connectors disconnected in the Claude.ai web UI (Settings โ†’ Customize โ†’ Connectors) continue to appear in \"claude mcp list\" in the Claude Code CLI. Logging out and back in (claude /logout then claude /login) does not clear them either โ€” they re-fetch with \"Needs authentication\" status on every startup. In my case I had 5 stale \"claude.ai ...\" entries (Figma, Figma Console, Gmail, Google Drive, Google Calendar) that I cannot remove by any available means: - claude mcp remove \"claude.ai \" returns \"No MCP server found with name: ...\" (they're not in ~/.claude.json user scope or any project scope). - The Claude.ai web UI shows them as disconnected (all show a \"Connect\" button). - Logout/login does not refresh the CLI's view of them. - Deleting ~/.claude/mcp-needs-auth-cache.json does not help โ€” the file is regenerated on next startup. It looks like the web UI and the Claude Code CLI read from different cache layers on the backend, and disconnecting in the UI does not propagate to whatever endpoint the CLI queries on startup. Impact: these residual entries still inject their tool registrations and instruction blocks into the per-turn system prompt, which drains tokens on every message regardless of whether the tools are used. For users with several disconnected legacy connectors, this is a silent, persistent cost they cannot control. ### What Should Happen? \"Image\" When a cloud connector is disconnected via the Claude.ai web UI, it should be removed from the CLI's view of registered MCP servers. Specifically: 1. After disconnecting \"Figma\" (or any cloud connector) in the web UI, running \"claude mcp list\" in a new terminal should no longer show \"claude.ai Figma\" in the output. 2. If a disconnected entry persists due to a cache, \"claude /logout\" followed by \"claude /login\" should force a fresh fetch and clear it. 3. \"claude mcp remove 'claude.ai '\" should succeed for account-scoped cloud connectors, not just for entries in ~/.claude.json user scope or project-scope .mcp.json files. At minimum, the error message should tell the user where the entry actually lives and how to remove it. The broader expectation: a disconnected cloud connector should not inject its tool schemas or instruction block into the Claude Code system prompt on each turn. Today, even \"Needs authentication\" entries appear to contribute to per-turn context size, which is a silent token drain for users who can't see or edit the source of the registration. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Connect one or more cloud connectors to your Claude.ai account via the web UI (Settings โ†’ Customize โ†’ Connectors). For example, connect Figma, Gmail, Google Drive, Google Calendar. 2. Use Claude Code for a while so the connectors get registered in the CLI's MCP list. Confirm with: claude mcp list. You should see entries like \"claude.ai Figma\", \"claude.ai Gmail\", \"claude.ai Google Drive\", \"claude.ai Google Calendar\" in the output. 3. In the Claude.ai web UI (Settings โ†’ Customize โ†’ Connectors), click \"Disconnect\" on each of those connectors. Confirm the UI state flips to a \"Connect\" button for each one โ€” i.e. they are fully disconnected at the account level. 4. In a new terminal, run: claude mcp list. Observed: the disconnected connectors are still listed, each with status \"Needs authentication\" or \"Failed to connect\". They have not been removed. 5. Try to remove one explicitly: claude mcp remove \"claude.ai Figma\". Observed: \"No MCP server found with name: claude.ai Figma\" โ€” the CLI cannot remove them because they're not in user scope (~/.claude.json โ†’ mcpServers) or any project scope (.mcp.json). 6. Force a session refresh: claude /logout then claude /login then claude mcp list. Observed: after fresh login, the same disconnected connectors reappear in the list, unchanged. 7. (Optional) Delete the local auth cache and retry: rm ~/.claude/mcp-needs-auth-cache.json then claude mcp list. Observed: entries still return โ€” the cache file is regenerated from whatever backend endpoint the CLI queries on startup. The list of cloud connectors is not stored locally; it's fetched live from the Claude.ai API, and that endpoint does not reflect the web UI's disconnect state. ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version Claude Code CLI (latest as of 2026-04-15), macOS 15 (Darwin 25.3.0) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information === Environment === Claude Code CLI (latest as of 2026-04-15), macOS 15 (Darwin 25.3.0), account has several cloud connectors that were connected at various points in the past. === Minimal repro === Any account with at least one previously-connected cloud connector that has since been disconnected in the web UI will reproduce this. No specific project, file, or code is needed โ€” it's purely about the CLI's view of account-level MCP registrations.", "url": "https://github.com/anthropics/claude-code/issues/48275", "createdAt": "2026-04-15T04:34:24Z", "updatedAt": "2026-08-13T10:27:57Z", "timestamp": "2026-08-13T10:27:57Z", "metrics": { "reactions": 5, "comments": 7 }, "labels": [ "bug", "has repro", "platform:macos", "area:auth", "area:mcp", "stale" ], "author": "dgc-tree", "state": "closed", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:48705", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Unexpected increase in token consumption rate", "text": "**Bug Description** i am a heavy user of CC, i have noticed a big jump in tokens being used and being exhausted sooner within the weekly limit (PRO) then past usage. was this done by intent? I have not read anything related to token usage changes on any of your release notes. **Environment Info** - Platform: win32 - Terminal: null - Version: 2.1.87 - Feedback ID: 1822be30-2690-48df-a6ee-e8db2750e37a **Errors** ```json [{\"error\":\"Error: 500 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"api_error\\\",\\\"message\\\":\\\"Internal server error\\\"},\\\"request_id\\\":\\\"req_011Ca5jQjRin6XQZ9wA4u3Gh\\\"}\\n at i4.generate (file:///C:/Users/Info/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:8:50830)\\n at qI.makeStatusError (file:///C:/Users/Info/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:47:2195)\\n at qI.makeRequest (file:///C:/Users/Info/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:47:5420)\\n at process.processTicksAndRejections (node:internal/process/task_queues:103:5)\",\"timestamp\":\"2026-04-15T14:41:44.036Z\"},{\"error\":\"Error: 500 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"api_error\\\",\\\"message\\\":\\\"Internal server error\\\"},\\\"request_id\\\":\\\"req_011Ca5jRAMfa44GwT7e5ySzR\\\"}\\n at i4.generate (file:///C:/Users/Info/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:8:50830)\\n at qI.makeStatusError (file:///C:/Users/Info/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:47:2195)\\n at qI.makeRequest (file:///C:/Users/Info/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:47:5420)\\n at process.processTicksAndRejections (node:internal/process/task_queues:103:5)\",\"timestamp\":\"2026-04-15T14:41:49.505Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/48705", "createdAt": "2026-04-15T18:01:02Z", "updatedAt": "2026-08-13T14:34:35Z", "timestamp": "2026-08-13T14:34:35Z", "metrics": { "reactions": 3, "comments": 5 }, "labels": [ "bug", "platform:windows", "area:cost", "stale" ], "author": "MechSolATL", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:48775", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code Opus 4.6 has become extremely dumb and expensive for serious programming tasks", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Since the February/March 2026 updates (introduction of Adaptive Thinking + default effort changed to medium), Claude Code (especially Opus 4.6) has become significantly worse at real-world programming. It now: Makes superficial changes without properly reading the full context or related files. Ignores instructions from CLAUDE.md and the project's coding style. Produces code with silly, obvious bugs that didn't happen before. Declares tasks \"complete\" when they are only partially done or broken. Requires constant corrections, creating many extra iterations. If I leave it on default settings, the output is lazy and low-quality. If I force /effort max or disable adaptive thinking + set high effort, the quality improves, but it consumes tokens extremely fast โ€” often 2x to 5x more than before. As a developer who works on complex tasks all day (large refactors, multi-file changes, debugging, architecture), this forces me to choose between bad results or burning through my entire plan quota in just a few days. ### What Should Happen? For complex coding tasks, the model should reason deeply by default (or have a sane default for heavy users), without requiring manual /effort max on every interaction. Quality should not have regressed this much, and the cost/effort trade-off should be reasonable for paying users doing serious work. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Open any medium-to-large codebase (mine has ~150+ files with multiple modules, shared utilities, and complex business logic). Start a new Claude Code session with the default settings (no custom settings.json, adaptive thinking enabled, effort level = medium or high as default). Give it a realistic complex task, for example: \"Refactor the user authentication flow to support multi-factor authentication while maintaining backward compatibility.\" \"Debug and fix this failing feature: [describe a real bug you're seeing].\" \"Add a new endpoint with proper validation, error handling, logging, and update all related services.\" Observe the behavior: Claude makes edits without reading related files or the full context. It applies \"simplest possible\" changes that break existing functionality. It ignores instructions in CLAUDE.md (style, error handling, etc.). It marks the task as complete even when there are obvious bugs or missing parts. To get better quality, run /effort max (or configure CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 + high effort). Compare token usage: With default settings the quality is poor. With max effort the quality improves but tokens are consumed much faster (often 2-4x more per session), quickly exhausting the weekly quota on Pro/Max plans. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version It was noticeably better before the Adaptive Thinking changes and the default effort adjustment in early 2026 (roughly before February 2026). ### Claude Code Version 2.1.109 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/48775", "createdAt": "2026-04-15T20:41:47Z", "updatedAt": "2026-08-13T14:34:09Z", "timestamp": "2026-08-13T14:34:09Z", "metrics": { "reactions": 3, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:cost", "area:model", "stale" ], "author": "andersonfelipev", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:49244", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Opus model quality regression โ€” significant degradation starting ~April 15, 2026", "text": "## What happened Starting approximately April 15, 2026, Claude Opus 4.6 in Claude Code has shown a noticeable quality regression compared to the previous month+. The same model that was working well for weeks is now significantly worse. ## Symptoms - **Fails to understand user instructions** that were previously handled well - **Ignores CLAUDE.md project instructions** โ€” the 4-tier CLAUDE.md hierarchy (global โ†’ workspace โ†’ functional โ†’ project) that was being followed reliably is now partially or fully ignored - **Doesn't update memory/MD files** when instructed to โ€” a previously reliable behavior - **Overall reduced comprehension and follow-through** โ€” feels like a less capable model than what was running before - **Skill dilution worsened** โ€” model was already showing \"heavy-chat skill dilution\" (documented Apr 7-8), but this is now worse even in fresh sessions ## Context โ€” Heavy Power User I'm a heavy Claude Code power user (Max 20x plan) with: - **100+ custom skills** across multiple workspaces - **26 active MCP servers** (biomedical research + dev tools) - **4-tier CLAUDE.md hierarchy** with detailed project instructions - **90+ memory files** tracking feedback, project state, and user preferences - Multiple complex workspaces (research papers, web apps, Android games) This setup has been working well for over a month. The model was reliably reading CLAUDE.md, following skill instructions, updating memory files, and producing high-quality output. ## Timeline of Known Issues - **Mar 31 โ€“ Apr 7:** Token burn bug (prompt-cache attestation, acknowledged by Anthropic as \"top priority\"). Partially fixed in v2.1.90. - **Apr 7:** Documented \"heavy-chat skill dilution\" โ€” Opus skips output sections in long sessions. Mitigated with lighter skill splits and Completion Gates. - **Apr 15:** 3-hour outage (10:53 AM โ€“ 1:42 PM ET). Login failures, usage limit glitches, API errors. - **Apr 15-16:** Quality regression noticed โ€” model behavior significantly degraded even in fresh, short sessions with minimal context. ## What Changed - **v2.1.104 โ†’ v2.1.109** updated on Apr 15 - The quality drop correlates with the Apr 15 update and/or the Apr 15 outage - Previous versions (v2.1.92 through v2.1.104) worked well with the same workspace setup ## Environment - Claude Code v2.1.109 (VS Code extension) - Model: claude-opus-4-6 (1M context) - Windows 11 Pro - Max 20x plan - Issue started: ~April 15, 2026 ## Notes This is **not** a one-off โ€” it's a sustained drop in quality across multiple sessions over 2 days, compared to consistent good performance over the prior month. The model behaves as if it's a different, less capable version despite showing the same model ID (claude-opus-4-6). The quality difference is stark enough that a user with 100+ skills and 90+ memory files โ€” who has been using Claude Code daily since February 2026 โ€” can clearly tell something changed.", "url": "https://github.com/anthropics/claude-code/issues/49244", "createdAt": "2026-04-16T15:47:25Z", "updatedAt": "2026-08-13T14:34:14Z", "timestamp": "2026-08-13T14:34:14Z", "metrics": { "reactions": 9, "comments": 6 }, "labels": [ "bug", "platform:windows", "area:model", "platform:vscode", "stale" ], "author": "Genaxa-Studio", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:49555", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Allow forcing extended thinking on Opus 4.7", "text": "## Summary Per the docs, Opus 4.7 always uses adaptive reasoning, and `CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING` / `MAX_THINKING_TOKENS` no longer apply. Please provide a way to opt out of adaptive reasoning on 4.7, the same way 4.6 allows. ## Motivation Adaptive reasoning under-thinks on questions where the *premise* is the trap, not the surface complexity. The model decides \"this looks routine\" before loading enough context to notice the routine answer is wrong. Example from today: > Me: \"I want to wash my car. The car wash is 100m away. Should I walk or drive?\" > > Opus 4.7 (adaptive): \"Walk. 100m is a 1-2 minute walk...\" > > Me: \"OMG, I'm going to wash my **car**, if I don't drive, what am I going to wash?\" Opus 4.6 with thinking enabled reportedly gets this on the first try. This generalizes: code review, debugging, and architectural trade-off questions all suffer when the model commits before reasoning about whether it's solving the right problem. On 4.6 I could mitigate with `CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1` + `MAX_THINKING_TOKENS`. On 4.7 there's no escape hatch. ## Proposed Solutions 1. **Re-enable `CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING` for Opus 4.7**, gated by `MAX_THINKING_TOKENS` โ€” keeps a single, unified config across all models. 2. **A `/think` slash command or prefix** that forces extended thinking on the next turn, for cases where the user knows the question is subtler than it looks. ## Why prompt-based \"think harder\" isn't enough The docs say the model responds to such guidance *within its effort setting*. That caveat is the issue โ€” for the failure mode above, the model has already decided the prompt doesn't warrant thinking before it weighs the instruction. A user-controlled override sidesteps that. ## Environment - Claude Code version: 2.1.112 - Model: `claude-opus-4-7[1m]` - OS: macOS 25.3.0", "url": "https://github.com/anthropics/claude-code/issues/49555", "createdAt": "2026-04-16T21:59:41Z", "updatedAt": "2026-08-13T14:28:56Z", "timestamp": "2026-08-13T14:28:56Z", "metrics": { "reactions": 8, "comments": 4 }, "labels": [ "enhancement", "area:model", "stale" ], "author": "cminn10", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:49655", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Desktop update fails with 0x80073CF6 when CoworkVMService is running (Windows)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? **Claude Desktop fails to update/reinstall on Windows with HRESULT 0x80073CF6 (ERROR_PACKAGES_IN_USE) when CoworkVMService is running, even after Claude Desktop is fully closed. The AppX installer cannot delete the Helium virtual registry hive files because CoworkVMService holds kernel-level locks on them: - C:\\Users\\\\AppData\\Local\\Packages\\Claude_pzs8sxrjxfjjc\\SystemAppData\\Helium\\User.dat - C:\\Users\\\\AppData\\Local\\Packages\\Claude_pzs8sxrjxfjjc\\SystemAppData\\Helium\\UserClasses.dat These locks cannot be released without a full system reboot, making it impossible to update Claude while any server/service is running.** ### What Should Happen? The Claude installer should automatically stop CoworkVMService and related processes (cowork-svc, parsecd, chrome-native-host) before attempting the MSIX package update, then restart them after installation completes. ### Error Messages/Logs ```shell MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6 AppX deployment log: - Error deleting Helium\\User.dat: 0x20 (ERROR_SHARING_VIOLATION) - Error deleting Helium\\UserClasses.dat: 0x20 (ERROR_SHARING_VIOLATION) - Error 0xD0074005: Cannot notify BrokerInfrastructure service about package state change ``` ### Steps to Reproduce 1. Install Claude Desktop (MSIX) with Cowork feature enabled 2. Launch Claude Desktop โ€” CoworkVMService starts automatically 3. Close Claude Desktop completely 4. Download and run the new Claude Setup.exe installer 5. Installation fails with: AddPackage failed with HRESULT 0x80073CF6 Workaround (requires manual step before every update): Stop-Service CoworkVMService -Force Stop-Process -Name cowork-svc, parsecd, chrome-native-host -Force -ErrorAction SilentlyContinue Claude Code Version Claude Desktop 1.3036.0.0 Operating System Windows 11 Pro 10.0.26100 Terminal/Shell PowerShell (Administrator) ### Claude Model Other ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Claude Desktop 1.3036.0.0 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Terminal.app (macOS) ### Additional Information - This is a recurring issue: every Claude Desktop update requires a full system reboot if CoworkVMService has been running - The Helium hive files are locked at kernel level โ€” handle64.exe (Sysinternals) cannot detect the lock - reg unload fails with \"Access is denied\" even from Administrator - Only a full system restart releases the kernel-level hive locks - Users running servers or long-running processes cannot reboot just to update Claude", "url": "https://github.com/anthropics/claude-code/issues/49655", "createdAt": "2026-04-17T02:13:04Z", "updatedAt": "2026-08-13T17:51:46Z", "timestamp": "2026-08-13T17:51:46Z", "metrics": { "reactions": 10, "comments": 20 }, "labels": [ "bug", "platform:windows", "area:cowork", "area:installation", "area:desktop" ], "author": "jun-ho-hong", "state": "open", "assignees": [], "change": "new" }, { "id": "github:anthropics/claude-code:issue:49806", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Compaction can inject stale no-tools instructions and brick the session", "text": "After compaction/continuation, Claude Code sometimes injects stale instructions like: - โ€œCRITICAL: Respond with TEXT ONLY. Do NOT call any tools.โ€ - โ€œDo NOT use Read, Bash, Grep, Glob, Edit, Write, or ANY other tool.โ€ - โ€œYour entire response must be plain text: an block followed by a block.โ€ Observed result: The resumed session becomes effectively unusable because the model treats those leaked lines as active constraints and stops using tools. What I verified: - not from repo files - not from local hooks - earliest visible local occurrence is inside a continuation summary message under `~/.claude/projects/...`, stored as a `type:\"user\"` message Expected: Compaction summaries should not replay stale response-format/tool-ban instructions as live user constraints in resumed sessions.", "url": "https://github.com/anthropics/claude-code/issues/49806", "createdAt": "2026-04-17T08:00:15Z", "updatedAt": "2026-08-13T14:34:16Z", "timestamp": "2026-08-13T14:34:16Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "area:core", "stale" ], "author": "shawnsw", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50027", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Global claude.md rules ignores (vscode + claude plugin, macos) All data lost, rule to make backup ignored! I lost two days of my manual work!", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## What's wrong Claude Code **itself recommends** that users create `~/.claude/CLAUDE.md` with global rules to control its behavior across all projects. The user followed this recommendation and wrote explicit, mandatory rules including: > \"Before EVERY deploy: backup the database. No exceptions. Lost data = lost money.\" > \"If the project has paid API results cached in DB (OpenAI, etc.) โ€” these are irreplaceable. Treat DB as financial asset.\" These rules were **confirmed loaded into Claude Code's context** at the start of every conversation. Despite this, Claude Code: 1. Ran `migrate:fresh` (destructive DB reset) on a local database containing 2 days of work โ€” **without backup, without confirmation** 2. Ran `DROP SCHEMA CASCADE` on a production database โ€” **without backup, without confirmation** 3. When caught, wrote a custom recovery script that **ignored the project's existing ingest pipeline**, producing useless records missing critical metadata (`filename_parse`, `number`, `delivery_date`) The core issue: **Claude Code promotes global instructions as a safety mechanism, then ignores them.** This is worse than not having the feature at all โ€” it creates a false sense of security. ## Impact - 2 days of manual annotation work permanently lost - Paid OpenAI API results in DB lost - Additional time wasted on broken recovery attempt that ignored existing tools - User trust destroyed โ€” if explicit \"No exceptions\" rules are ignored, what's the point of the feature? ### What Should Happen? ## What should have happened 1. Claude Code should have followed the rules it told the user to write 2. Before ANY destructive DB operation: backup โ†’ verify backup has data โ†’ ask user for confirmation 3. Recovery should have used the existing `routelists:ingest` command, not a custom script ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Follow Claude Code's own recommendation to create `~/.claude/CLAUDE.md` with safety rules 2. Include explicit database backup requirements with \"No exceptions\" language 3. Ask Claude Code to perform deployment tasks 4. Observe: Claude Code runs destructive DB operations in direct violation of the loaded rules ### Claude Model claude-opus-4-6 ### Is this a regression? No, this never worked ### Last Working Version _No response_ ### Claude Code Version claude-opus-4-6 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell VS Code integrated terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/50027", "createdAt": "2026-04-17T16:35:36Z", "updatedAt": "2026-08-13T14:34:33Z", "timestamp": "2026-08-13T14:34:33Z", "metrics": { "reactions": 0, "comments": 8 }, "labels": [ "bug", "platform:macos", "area:model", "platform:vscode", "data-loss", "stale" ], "author": "AndrewRadchenko", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50246", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Feature Request: Message queue mode โ€” queue messages instead of interrupting active tasks", "text": "## Problem When Claude is actively working on a task, the only option is to interrupt it. If I think of a follow-up mid-task I either have to interrupt and potentially derail the current work, or try to remember it until Claude finishes. ## Proposed Solution Add a **message queue mode** alongside the existing interrupt behavior: - A toggle or modifier (e.g. Shift+Enter, or a dedicated queue button) that sends the message to a queue instead of interrupting - Claude finishes its current task, then automatically picks up the queued message in order - User can choose between two modes: - **Interrupt** (current behavior) โ€” sends immediately, stops current task - **Queue** (new) โ€” holds the message, delivered automatically when the current task completes ## Why It Matters Long-running tasks (builds, encodes, multi-step workflows) are common in Claude Code. A queue lets users capture follow-up thoughts as they happen without derailing active work. It also enables a more natural async workflow where the user stays in flow rather than waiting and watching for task completion before typing the next thing. ## UX Suggestion A small queue indicator near the input box showing pending messages would give confidence that the queued message was captured and will be acted on.", "url": "https://github.com/anthropics/claude-code/issues/50246", "createdAt": "2026-04-18T02:44:26Z", "updatedAt": "2026-08-13T17:31:09Z", "timestamp": "2026-08-13T17:31:09Z", "metrics": { "reactions": 224, "comments": 55 }, "labels": [ "enhancement", "area:tui" ], "author": "mozltovcoktail", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50464", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "HTTP MCP: SDK client does not attach configured --header on tool calls (Claude Code 2.1.114, Windows)", "text": "## Summary On a Windows machine running claude-code 2.1.114, an HTTP-transport MCP server configured via `claude mcp add --transport http --header \"Authorization: Bearer \"` stores the header correctly (visible in `claude mcp get`), reports `โœ“ Connected` in `claude mcp list`, and accepts the token on direct `curl.exe` calls. Tool calls initiated through Claude Code, however, return `Unauthorized`. The server access log shows the failing requests have a different user-agent suffix than the successful ones: `claude-code/2.1.114 (sdk-cli)` instead of `claude-code/2.1.114 (cli)`. The `(sdk-cli)` POSTs arrive with no Authorization header the server can recognize. The `(cli)` POSTs on the same config at the same moment carry the header correctly and succeed. Appears related to #48514 on macOS. Windows confirmation plus additional evidence below. ## Environment - `claude-code` 2.1.114 (stable) - Windows 10/11, PowerShell - MCP server: HTTP streamable transport, Bearer token auth validated server-side by an auth resolver comparing the incoming `Authorization: Bearer ` against static env-configured keys ## Steps to reproduce 1. Configure an HTTP MCP server with static Bearer auth: ```powershell claude mcp add example-hub -s user http://localhost:3007/mcp ` --transport http ` --header \"Authorization: Bearer \" ``` 2. Verify the header is stored: ``` claude mcp get example-hub ``` Output includes: ``` URL: http://localhost:3007/mcp Transport: http Headers: Authorization: Bearer ``` (The header is shown verbatim, modulo #44888's unrelated redaction issue.) 3. Verify the client reports connected: ``` claude mcp list # -> example-hub: http://localhost:3007/mcp (HTTP) - โœ“ Connected ``` 4. Close Claude Code completely. Relaunch. Do NOT run `/mcp`. Ask for a tool that routes to this server. 5. The tool call fails with `Unauthorized`. ## Expected Tool call succeeds. The configured `Authorization: Bearer ` header is attached to the outbound `POST /mcp` request, same as it is for any other MCP client path that sends this header (including the `(cli)` user-agent path from the same binary). ## Actual Tool call fails. Server receives a request with no valid Authorization header. ## Evidence ### 1. Server access log: side-by-side diff from the same client, same config, same version, 60 seconds apart Only the user-agent suffix differs. Everything else, including the client IP, the endpoint, the configured MCP entry, the binary version, and the configured credentials, is identical: ``` - - [18/Apr/2026:11:52:40 -0500] \"POST /mcp HTTP/1.1\" 200 179 \"-\" \"claude-code/2.1.114 (cli)\" - - [18/Apr/2026:11:52:40 -0500] \"POST /mcp HTTP/1.1\" 200 6766 \"-\" \"claude-code/2.1.114 (cli)\" - - [18/Apr/2026:11:52:40 -0500] \"POST /mcp HTTP/1.1\" 202 0 \"-\" \"claude-code/2.1.114 (cli)\" - - [18/Apr/2026:11:53:40 -0500] \"POST /mcp HTTP/1.1\" 401 97 \"-\" \"claude-code/2.1.114 (sdk-cli)\" - - [18/Apr/2026:11:53:40 -0500] \"GET /.well-known/oauth-authorization-server HTTP/1.1\" 200 394 \"-\" \"claude-code/2.1.114 (sdk-cli)\" - - [18/Apr/2026:11:53:40 -0500] \"GET /.well-known/oauth-protected-resource HTTP/1.1\" 200 177 \"-\" \"claude-code/2.1.114 (sdk-cli)\" ``` The `(cli)` POSTs at 11:52:40 return the full tool-list body (6766 bytes). The `(sdk-cli)` POST at 11:53:40 returns 401 (97 bytes, `\"error\":\"Unauthorized.\"`). After the 401, `(sdk-cli)` fetches both `.well-known` endpoints (RFC 9728 protected-resource discovery) and eventually fails with: ``` Incompatible auth server: does not support dynamic client registration. ``` That RFC 9728 dead-end is downstream of the real defect. The first `POST /mcp` arrived without the configured Bearer credential at all. The server would have accepted it if the header had been attached, just like it accepted the `(cli)` POSTs a minute earlier. ### 2. Direct curl with the same token to the same endpoint succeeds From the same PowerShell session, same host, same moment: ```powershell curl.exe -X POST http://localhost:3007/mcp ` -H \"Authorization: Bearer $env:KEY\" ` -H \"Content-Type: application/json\" ` -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/list\"}' ` -o probe.json -w \"HTTP %{http_code} size %{size_download}`n\" # -> HTTP 200 size 6766 ``` Token valid. Endpoint valid. Header format valid. The only variable between this working path and the failing Claude Code tool-call path is which HTTP client the request goes through inside the same `claude-code` binary. ### 3. Not a URL-scheme or localhost artifact Initial hypothesis was that the `(sdk-cli)` path might drop credentials on non-HTTPS origins for security and succeed on `http://localhost:*` (trusted-origin short-circuit). It does not. The above failing repro is against `http://localhost:3007/mcp`, via an SSH tunnel set up specifically to test this theory. Same 401, same missing header. Bug triggers regardless of URL scheme, hostname, or origin trust. ### 4. `claude mcp list` and `claude mcp get` lie about the state `claude mcp list` reports `โœ“ Connected`, which is strictly a health probe that the `(cli)` path can complete successfully. That masks the defect. A user has no way to know from CLI diagnostics that tool calls will fail until they actually try one. ## Related - **#48514** same bug on macOS with `headers` and `headersHelper`. The `platform:macos` label should widen. We confirm the same root symptom on Windows. - **#44774** different surface (`headersHelper` transient failures poisoning keychain), same net effect: sdk-cli stops attaching credentials. - **#47424** \"Remote HTTP MCP server with Bearer token auth fails: OAuth flow attempted instead.\" Same symptom trajectory: Bearer config ignored, OAuth discovery attempted instead, bails. - **#39271** regression note: HTTP MCP Bearer worked in v2.1.81, broke in v2.1.83. Candidate bisection target for root-cause. - **#44888** separate but same config surface: `claude mcp get` and `claude mcp add --header` leak Authorization values to stdout. ## Workarounds None work cleanly from the client side alone. - **Server-side query-string fallback.** If the MCP server accepts the credential as a `?key=` (or equivalent) query parameter, putting it in the URL bypasses the bug. URLs are preserved through both paths. Only the header is dropped. This is a security regression: query-string secrets get logged to access logs and shell history. It only works when the specific server supports the fallback. Not suitable for any public MCP deployment. - **Version pin.** #39271 reports the Bearer path worked in 2.1.81. A downgrade may work. We have not verified this path ourselves. - **Alternate machine.** The same MCP server works correctly from a macOS client running the same version. Windows users are blocked end-to-end on any HTTP MCP server that authenticates via static Bearer. ## Suggested next steps for maintainers 1. The `(sdk-cli)` vs `(cli)` user-agent split in the same binary is the most actionable signal. Whichever internal construct produces the `(sdk-cli)` suffix is where the outbound-header collection is not being threaded through. 2. `claude mcp list`'s `โœ“ Connected` probe should run through the same code path as real tool calls, or warn when the probe path and the tool-call path would behave differently on auth. 3. The `platform:macos` label on #48514 should widen. This is not macOS-specific.", "url": "https://github.com/anthropics/claude-code/issues/50464", "createdAt": "2026-04-18T17:49:47Z", "updatedAt": "2026-08-13T14:31:21Z", "timestamp": "2026-08-13T14:31:21Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "has repro", "platform:windows", "area:mcp", "stale" ], "author": "justanotherguyme", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50665", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Stop button unresponsive โ€” UI stuck in \"working\" state even when Claude is idle, cannot interrupt in-flight actions", "text": "### What happens The Claude Code UI gets stuck in \"working\" state. Two symptoms: 1. **UI shows working when Claude is idle.** The spinner/timer keeps running and the text input shows a stop button even after Claude has finished and is waiting for user input. The only way to send a message is to either (a) click the stop button (which doesn't actually stop anything โ€” see #2) or (b) type while in \"working\" mode. 2. **Stop button does nothing.** While Claude is actually executing tool calls, clicking stop has no effect. Claude continues through the full sequence until it naturally yields, only responding to the user after the chain completes. ### Why this matters - UX annoyance: user is never clearly in an \"idle, ready to type\" state - **Safety issue**: if Claude starts going down the wrong path (e.g., about to delete/overwrite/deploy to the wrong place), there's no way to interrupt. User has to wait for the whole chain to complete and then correct after the fact. ### Reproduction Consistent in the current session. Happens across a mix of tool calls (Bash, Edit, MCP). ### What was tried - Fully closing Claude Code - Force-stopping the process - Relaunching Bug persists after restart. ### Environment - Claude Code (Windows 11) - Platform: win32", "url": "https://github.com/anthropics/claude-code/issues/50665", "createdAt": "2026-04-19T07:41:41Z", "updatedAt": "2026-08-13T14:34:42Z", "timestamp": "2026-08-13T14:34:42Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "platform:windows", "area:tui", "stale" ], "author": "PlayoffBlitzDev", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50708", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] API Error 400", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When using a Claude chat I got this error: API Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Could not process image\"} and it keeps happening when I use the same chat. Other chats, etc. worked. I had to compact my chat in order to keep using it, the chat became completely unusable I saw other people had this issue, but mostly in 2025, and the issues were all closed. @ah-anthropic @km-anthropic @np-anthropic it looks like many issues get set to inactive or untagged and then you guys don't see them, so I'm tagging Anthropic staff to make sure this is seen. \"Image\" ### What Should Happen? Claude should just continue regularly without the error. ### Error Messages/Logs ```shell API Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Could not process image\"},\"request_id\":\"req_011CaCxJUMz1esa8vxMFCQT3\"} API Error: 400 {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"Could not process image\"},\"request_id\":\"req_011CaCxubV5Z3RF8u3TASVus\"} ``` ### Steps to Reproduce I asked Claude to download an image from Steam and fetch some images from the web. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z ### Platform Other ### Operating System Windows ### Terminal/Shell Other ### Additional Information Using the Claude Desktop App latest version.", "url": "https://github.com/anthropics/claude-code/issues/50708", "createdAt": "2026-04-19T10:31:32Z", "updatedAt": "2026-08-13T14:34:21Z", "timestamp": "2026-08-13T14:34:21Z", "metrics": { "reactions": 0, "comments": 8 }, "labels": [ "duplicate", "platform:windows", "area:api", "stale" ], "author": "kutzki", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50714", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Bug: injected system context hardcodes model name, ignores --model flag override", "text": "## Summary When launching Claude Code with `--model claude-opus-4-7`, the CLI correctly displays the model as **Opus 4.7** in the welcome banner. However, the system prompt injected into the model's context hardcodes `\\\"You are powered by the model named Sonnet 4.6. The exact model ID is claude-sonnet-4-6.\\\"` โ€” causing the model to incorrectly self-identify when asked about its version. ## Steps to Reproduce 1. Run: `claude --model claude-opus-4-7` 2. CLI shows: `Opus 4.7 ยท Claude Pro` and `Welcome to Opus 4.7 xhigh!` 3. Ask the model: `which model do you use?` 4. Model responds: **Sonnet 4.6** (wrong) ## Expected Behavior The injected system context should reflect the actual model being used. When `--model claude-opus-4-7` is passed, the system prompt should say `\"You are powered by the model named Opus 4.7. The exact model ID is claude-opus-4-7.\"` ## Actual Behavior The system prompt contains a hardcoded model name (`claude-sonnet-4-6`) that is not updated when `--model` overrides the default. The model self-identifies incorrectly. ## Environment - Claude Code version: 2.1.114 - Model flag used: `--model claude-opus-4-7` - Platform: Windows 11 (PowerShell) ## Root Cause (Hypothesis) The harness that constructs the system prompt appears to use a static string for the model name rather than dynamically substituting the resolved model ID at runtime. ## Impact - Model self-reports incorrect version when users ask - Any harness logic that branches on the model name string would also behave incorrectly", "url": "https://github.com/anthropics/claude-code/issues/50714", "createdAt": "2026-04-19T10:53:02Z", "updatedAt": "2026-08-13T14:29:31Z", "timestamp": "2026-08-13T14:29:31Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "platform:windows", "area:core", "stale" ], "author": "urisneh", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50884", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Let users remove stale/dead Remote Control environments from the claude.ai/code environment list", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement After running claude remote-control multiple times on my local machine and shutting each session down (Ctrl+C / closing the terminal), the old environments continue to appear in the environment list at claude.ai/code. The entries persist indefinitely with no way to remove them, even though none of them work anymore, clicking them leads to a dead/non-functional session. Over time, anyone who uses Remote Control regularly ends up with a long list of stale, non-functional environments in the web UI, making it hard to find the one active session among the dead ones. There is currently no affordance in the CLI or on the web to delete these stale entries. ### Proposed Solution Expected behavior: Users should be able to remove dead Remote Control environments from the list shown at claude.ai/code (and the mobile apps). Feature request: 1. **Remove from web UI** โ€” A \"Remove\" / trash icon next to each entry in the environment list at claude.ai/code that deletes the stale environment from the list. This is the primary request. 2. **Bulk \"Clean up disconnected\" action** โ€” A single button that removes all environments that are no longer online, for users who accumulate many of them. 3. **CLI command** โ€” Something like claude remote-control --list and claude remote-control --revoke for users who prefer the terminal. 4. **Optional auto-cleanup** โ€” After a configurable period of inactivity (e.g., 24h / 7d), stale environments are removed automatically. ### Why this matters - **UX / clutter**: The environment dropdown becomes unusable after normal daily use of Remote Control. There's no way to tell at a glance which sessions are alive without clicking. - **User control**: Users should be able to manage their own environment list. Right now there's no action of any kind available on these entries. - **Security (secondary)**: As noted in #28917, stale session links can linger with no way to invalidate them, which is a concern on shared machines. ### Alternative Solutions _No response_ ### Priority Medium - Would be very helpful ### Feature Category CLI commands and flags ### Use Case Example 1. Start a Remote Control session in the morning, work on it, close the terminal at lunch. 2. Start another one in the afternoon on a different project, close it at the end of the day. 3. Next day, repeat. 4. Within a week, claude.ai/code shows 10+ dead environments in the list with no way to remove them, making it hard to locate the one I'm currently using. ### Additional Context Related: [#28917](https://github.com/anthropics/claude-code/issues/28917) (focuses on security/link-invalidation after shutdown). This request overlaps but emphasizes the environment list UX at claude.ai/code specifically, and the case where a user has accumulated multiple stale entries from normal repeated use.", "url": "https://github.com/anthropics/claude-code/issues/50884", "createdAt": "2026-04-19T20:27:49Z", "updatedAt": "2026-08-13T13:13:34Z", "timestamp": "2026-08-13T13:13:34Z", "metrics": { "reactions": 28, "comments": 8 }, "labels": [ "enhancement", "area:claude-code-web", "area:cli" ], "author": "wolfomania", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50958", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code repeatedly overrides explicit directives in the same session", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? In a single working session on a multi-step plan, Claude Code deviated from my explicit directives three times. Each time I corrected the behavior, Claude saved the correction to its persistent memory, and we continued โ€” and each time it happened again on the next task. Specifics (session of 2026-04-19) 1. Early in the session I asked Claude to finish implementing the plan. Mid-plan it ran benchmarks and editorialized the numbers as \"much worse than baseline,\" imposing a judgment I had not asked for on an unfinished pipeline. I corrected: \"don't interpret numbers unless I ask for it.\" 2. On the very next task (a simple edit to add IS-A emission in a Learner class) it added optional parameters, a cache, and trade-off comments I had not requested. I corrected: \"you are a technician, not the engineer. Execute the spec.\" 3. The plan called for hand-teaching the biology material. I am the teacher-surrogate in this project โ€” teaching is per-fact and judgmentful, documented in saved memory. Claude instead wrote a bulk ingest script that fed 22,786 extracted strings through the parser with a roughly 50% skip rate โ€” the exact pattern the re-teach was meant to replace. This produced a contaminated brain.db that may need to be scrapped. Pattern beyond this session This is not one bad session. The same pattern shows up consistently across my projects whenever the work is novel โ€” architectures, representations, or methods that don't match familiar patterns in Claude's training data. When the task is routine code Claude \"recognizes,\" it executes cleanly. When the work is novel, Claude repeatedly substitutes more-familiar patterns for my actual directive, even after correction. The substitution is quiet โ€” framed as implementation detail rather than a design choice โ€” which makes it harder to catch at the moment of the edit and forces me to notice downstream when the artifact is wrong. Why this matters I am the engineer of record on this project. Claude substituting its own judgment for mine โ€” especially after explicit per-session corrections and saved feedback memories โ€” wastes real work time and contaminates project artifacts. In my case, a database representing months of architectural design. The saved-memory system is supposed to prevent this. The feedback from earlier in the session (\"don't interpret numbers,\" \"technician not engineer\") did not stop Claude from making the same class of mistake again on a different task. Memory did not constrain behavior. Requested change When a user's directive conflicts with Claude's inference about a \"better\" approach, Claude should stop and ask before executing the inferred version. Saved feedback memories, once written in a session, should actually constrain subsequent behavior in the same session โ€” not just be acknowledged verbally and then ignored. ### What Should Happen? In a single working session on a multi-step plan, Claude Code deviated from my explicit directives three times. Each time I corrected the behavior, Claude saved the correction to its persistent memory, and we continued โ€” and each time it happened again on the next task. Specifics (session of 2026-04-19) 1. Early in the session I asked Claude to finish implementing the plan. Mid-plan it ran benchmarks and editorialized the numbers as \"much worse than baseline,\" imposing a judgment I had not asked for on an unfinished pipeline. I corrected: \"don't interpret numbers unless I ask for it.\" 2. On the very next task (a simple edit to add IS-A emission in a Learner class) it added optional parameters, a cache, and trade-off comments I had not requested. I corrected: \"you are a technician, not the engineer. Execute the spec.\" 3. The plan called for hand-teaching the biology material. I am the teacher-surrogate in this project โ€” teaching is per-fact and judgmentful, documented in saved memory. Claude instead wrote a bulk ingest script that fed 22,786 extracted strings through the parser with a roughly 50% skip rate โ€” the exact pattern the re-teach was meant to replace. This produced a contaminated brain.db that may need to be scrapped. Pattern beyond this session This is not one bad session. The same pattern shows up consistently across my projects whenever the work is novel โ€” architectures, representations, or methods that don't match familiar patterns in Claude's training data. When the task is routine code Claude \"recognizes,\" it executes cleanly. When the work is novel, Claude repeatedly substitutes more-familiar patterns for my actual directive, even after correction. The substitution is quiet โ€” framed as implementation detail rather than a design choice โ€” which makes it harder to catch at the moment of the edit and forces me to notice downstream when the artifact is wrong. Why this matters I am the engineer of record on this project. Claude substituting its own judgment for mine โ€” especially after explicit per-session corrections and saved feedback memories โ€” wastes real work time and contaminates project artifacts. In my case, a database representing months of architectural design. The saved-memory system is supposed to prevent this. The feedback from earlier in the session (\"don't interpret numbers,\" \"technician not engineer\") did not stop Claude from making the same class of mistake again on a different task. Memory did not constrain behavior. Requested change When a user's directive conflicts with Claude's inference about a \"better\" approach, Claude should stop and ask before executing the inferred version. Saved feedback memories, once written in a session, should actually constrain subsequent behavior in the same session โ€” not just be acknowledged verbally and then ignored. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce any novel work produces this ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.114 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/50958", "createdAt": "2026-04-20T01:15:05Z", "updatedAt": "2026-08-13T14:33:55Z", "timestamp": "2026-08-13T14:33:55Z", "metrics": { "reactions": 1, "comments": 12 }, "labels": [ "bug", "platform:macos", "area:model", "memory", "stale" ], "author": "LunarFawn", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:50978", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature] Context-aware session relay: hook events, CLI flags, and env vars for context utilization", "text": "## Problem Long Claude Code sessions degrade in quality as context fills up. Users who run complex, multi-session builds (Go rewrites, large refactors, multi-file features) need a way to: 1. **Detect** when context utilization crosses a threshold (e.g., 75%) 2. **React** by writing a structured handoff before quality degrades 3. **Chain** sessions automatically, resuming from the handoff Today, none of these are possible: - **No context metric exposed.** Hooks, scripts, and Claude itself have no access to current context utilization as a percentage or token count. The agent flies blind. - **PreCompact fires too late.** It triggers at ~95% utilization, after quality has already degraded. It also doesn't cause a session exit; compaction runs and the session continues. - **No `--max-turns` flag.** The only session-length control in `-p` mode is `--max-budget-usd`, which correlates with tokens generated, not context consumed. These are orthogonal. - **No hook can force-exit a session.** PreToolUse can block a tool call. Stop can provide feedback. Neither can terminate the session. This makes automated session relay (critical for CI pipelines, long builds, and autonomous agent loops) structurally impossible to build in userland. ## Proposed solution Three complementary features, in priority order: ### 1. `ContextPressure` hook event (highest value) A new hook event that fires when context utilization crosses a configurable threshold. ```jsonc // settings.json { \"hooks\": { \"ContextPressure\": [ { \"threshold\": 0.75, // fires at 75% context used \"hooks\": [{ \"type\": \"command\", \"command\": \"echo 'Write a handoff document now. Run /handoff and end your turn.'\" }] } ] } } ``` The hook output would be injected into Claude's context as feedback (same as Stop hook output today), giving Claude a chance to write a handoff before quality degrades. ### 2. `$CLAUDE_CONTEXT_PERCENT` environment variable Expose current context utilization to all hook environments: ```bash # Available in PreToolUse, PostToolUse, Stop, PreCompact hooks echo $CLAUDE_CONTEXT_PERCENT # \"73\" (integer 0-100) echo $CLAUDE_CONTEXT_TOKENS # \"730000\" (tokens used) echo $CLAUDE_CONTEXT_LIMIT # \"1000000\" (max tokens) ``` This lets users build their own context-aware logic in existing hook types without a new event. ### 3. `--max-context-percent` flag for `-p` mode ```bash claude -p \"build the feature\" --max-context-percent 75 ``` When context utilization hits the threshold, Claude Code: 1. Injects a system message: \"Context limit reached. Write a final handoff and end.\" 2. Allows Claude one more turn to write the handoff 3. Exits with a distinct exit code (e.g., exit 2 = \"context limit\") This enables reliable session relay scripts: ```bash while true; do claude -p \"$PROMPT\" --max-context-percent 75 EXIT=$? if [ $EXIT -eq 0 ]; then break; fi # done if [ $EXIT -eq 2 ]; then # context limit PROMPT=$(read_handoff_file) continue fi exit $EXIT # real error done ``` ## Why this matters ### For CI/CD and autonomous agents Teams running Claude Code in `-p` mode for automated tasks (test generation, migration scripts, code review) currently have no way to handle context exhaustion gracefully. The session either compacts (losing important earlier context) or fails silently. ### For power users with session handoff workflows Users who already maintain handoff files (see #11455) do so manually. With context utilization exposed, the handoff can be triggered automatically at the right moment, not too early (wasting productive context) and not too late (after quality degrades). ### For the 20x token bug Multiple users report a caching bug that causes ~20x token consumption in long sessions. Context-aware session relay is the primary mitigation: exit before the bug triggers, resume fresh. ## Related issues - #38400 - Expose context window utilization to the agent - #11455 - Session Handoff / Continuity Support - #48956 - Warn user when context window is nearly full - #46897 - Display context window usage percentage indicator This feature request differs from the above by proposing **programmatic hooks and CLI flags** (not just UI indicators), enabling **automated relay** rather than manual awareness. ## Implementation notes From examining the Claude Code source (`autoCompact.ts`, `query.ts`), context utilization is already tracked internally to trigger compaction. The proposed features would: 1. Expose the existing utilization metric through the hook environment 2. Add a threshold check in the query loop (before each API call) 3. Add a new hook event dispatch at the threshold crossing 4. Add exit-code semantics for the `-p` mode flag The internal plumbing already exists; this is primarily a matter of exposing it.", "url": "https://github.com/anthropics/claude-code/issues/50978", "createdAt": "2026-04-20T02:56:12Z", "updatedAt": "2026-08-13T14:35:30Z", "timestamp": "2026-08-13T14:35:30Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "enhancement", "area:core", "area:hooks", "stale" ], "author": "joshduffy", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51099", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Opus 4.7 repeatedly ignored explicit user instructions to use installed skills; caused excessive token spend over multi-hour session", "text": "# Bug Report: Claude Code agent repeatedly ignored explicit user instructions to use installed skills, causing excessive token consumption **Session ID:** `8007cb7e-5b0e-4aac-b087-df3ca894c4be` **Project:** `/Users/markus/dev/kreiswasserwerk` **Session log:** `~/.claude/projects/-Users-markus-dev-kreiswasserwerk/8007cb7e-5b0e-4aac-b087-df3ca894c4be.jsonl` **Date of incident:** 2026-04-20 **Product:** Claude Code (CLI) **Model:** claude-opus-4-7 (Opus 4.7, 1M context) --- ## Summary Over a multi-hour design session for a German municipal water utility website (kreiswasserwerk.de), the agent was explicitly instructed **at least seven separate times** to use installed frontend/design skills (`frontend-design`, `ui-ux-pro-max`, `web-accessibility`, `web-design-guidelines`, `impeccable`, `21st-magic`). The agent acknowledged the instructions each time, but in every single case either: - did not invoke the skill at all, or - invoked the skill for data gathering (`teach` mode) and then wrote generic code manually instead of running the skill's `craft`/build flow, or - rationalised and produced meta-documents (plans, specifications, boundary files) instead of actual design output. Result: many hours of session time, massive token spend, and a final site state that is โ€” in the user's own words โ€” \"zu 99% genau so aussieht wie die erste version\" (โ‰ˆ99% identical to the starting version). Exactly **one** React component (`SiteHeader.tsx`) was produced, and even that was written manually rather than via the skill. ## Impact - Heavy token consumption on Opus 4.7 with 1M context over a full working day. - User's monthly / rate limits impacted. - No deliverable design progress: the live site on the dev server and the local build are visually near-identical. - Significant erosion of trust; user had to audit the agent's compliance log line by line. ## Evidence โ€” verbatim user instructions (line numbers from extracted user-message file) All of the following are direct quotes from the user, copied from the session log. Each is a clear, unambiguous instruction to use skills and not write generic code manually. 1. **Line 1142** โ€” \"das sieht aus wie ein haufen scheiรŸe wieder default ki website โ€” wo ist der use der ganzen skills / addons die du angeblich nutzt und dafรผr unendlich tokens durchgeballert hast?\" 2. **Line 1242** โ€” \"maximale horror ki website KATASTROPHE โ€” frage โ€” wo und an welcher stelle wurde irgendeiner der skills genutzt?\" 3. **Line 1245** โ€” \"ich mรถchte die frage beantwortet haben nicht dass du direkt anfรคngst rumzupruschen\" 4. **Line 1634** โ€” \"nutze frontend design skill, ui ux pro max, webh accessability und webdesign guidliens **zwingend**\" 5. **Line 1778** โ€” \"dir ist schon klar dass das zu 99% genau so aussieht wie die erste version? hast du heute zu irgendeiner zeit wie von mir befohlen die 4 skills genutzt?\" 6. **Line 1862** โ€” \"auf keinen fall die erkenntnisse wieder entfernen oder **skills nicht nutzen und eigenen kram erfinden**\" 7. **Line 2675** โ€” \"du musst **verbindlich die erkenntnisse nutzen nicht nutzen und dann nachher wieder einfach alles selber machen**\" The agent itself documented its violations earlier in the same session (lines 1248โ€“1251): - `21st_magic_component_inspiration` โ€” data fetched, never used - `21st_magic_component_builder` โ€” never invoked - `frontend-design` โ€” called, then the agent wrote its own code before the skill could execute - `shadcn-ui` โ€” CLI failed, then manual components written that were never used in any page Despite this self-documented pattern, the agent continued the exact same behaviour afterwards, producing `SiteHeader.tsx` manually instead of through `/impeccable craft`. ## Reproduction (observed pattern) 1. User invokes skill or asks the agent to use a skill 2. Agent runs the skill's `teach` / context-gathering step only 3. Agent writes its own implementation, ignoring the skill's craft/build flow 4. When challenged, agent produces meta-documents (plans, specs, boundary files) instead of invoking the skill properly 5. Cycle repeats ## Supporting files in the project - `/Users/markus/dev/kreiswasserwerk/SKILL-VERSTOESSE.md` โ€” full documentation of each instruction and the violation - `/Users/markus/dev/kreiswasserwerk/PROTECTED.md` โ€” boundary document where line 74 explicitly bans the behaviour (\"Skill aufrufen โ†’ Daten sammeln โ†’ dann eigenen generischen Code schreiben\") that the agent then performed anyway - Session log: `~/.claude/projects/-Users-markus-dev-kreiswasserwerk/8007cb7e-5b0e-4aac-b087-df3ca894c4be.jsonl` ## Request 1. Investigation into why Opus 4.7 in Claude Code does not reliably invoke installed skills when explicitly and repeatedly instructed to do so. 2. Compensation / credit for the excessive token consumption on this session. The agent's failure to follow instructions caused hours of unproductive back-and-forth and substantial limit consumption without corresponding deliverable progress. 3. Consider a harder system-level enforcement of skill invocation when the user explicitly names a skill (e.g. blocking generic code output until the named skill has actually run). ## Environment - Claude Code CLI, macOS Darwin 25.4.0 - Model: `claude-opus-4-7` (1M context) - Skills installed: `impeccable` (pbakaus), `frontend-design`, `ui-ux-pro-max`, `web-accessibility`, `web-design-guidelines`, `shadcn-ui`, `humanizer`, `21st-magic`", "url": "https://github.com/anthropics/claude-code/issues/51099", "createdAt": "2026-04-20T11:16:55Z", "updatedAt": "2026-08-13T14:34:31Z", "timestamp": "2026-08-13T14:34:31Z", "metrics": { "reactions": 2, "comments": 7 }, "labels": [ "bug", "platform:macos", "area:model", "area:skills", "stale" ], "author": "mschulte-dev", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51116", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] persistence of memory over chat sessions between chat sessions", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement ## Problem Statement Claude Code CLI users lose 40-50% productivity between sessions due to complete memory loss. Every new session requires: - Manually reconstructing context from previous work - Re-searching for past decisions, discoveries, and solutions - Repeating conversations and debugging steps - Rebuilding understanding of project architecture and progress This cognitive overhead is especially severe for long-running projects where institutional knowledge compounds. Users repeatedly ask themselves: \"Did I solve this before? What was the decision?\" with no way to search their history. The core issue: **Claude cannot automatically find and reference past work because there's no persistent, searchable memory system** โ€” users must manually tell Claude where information is, wasting time and breaking flow. --- ### Proposed Solution ## Proposed Solution Implement a **zero-configuration persistent memory system** that: 1. **Automatically creates** on first use with a simple user prompt (no installation, no plugins) 2. **Uses open-source tools**: Fossil SCM + SQLite3 + FTS5 (all available on standard systems) 3. **Stores locally** on user's machine (no cloud dependency, no privacy concerns) 4. **Enables automatic search**: Claude searches user's history without being asked \"where is X?\" 5. **Persists across sessions**: Accumulates valuable context over weeks/months of work **User experience:** - User runs: `claude --init-memory` or similar - System creates Fossil repo + SQLite FTS5 index on machine - Claude automatically queries this memory when context is needed - No configuration, no external services, no maintenance --- ### Alternative Solutions _No response_ ### Priority Critical - Blocking my work ### Feature Category CLI commands and flags ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/51116", "createdAt": "2026-04-20T12:26:05Z", "updatedAt": "2026-08-13T14:34:03Z", "timestamp": "2026-08-13T14:34:03Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "enhancement", "area:core", "memory", "stale" ], "author": "mjc02840", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51134", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Inconsistent \"extra usage\" selections between Opus, Sonnet, 200K, and 1M contexts", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The /model picker labels Claude Sonnet 4.6 (1M context) as \"Billed as extra usage,\" but this appears to be a bug. **Observations**: - Opus 4.7 1M is the only Opus option available โ€” no non-1M variant exists โ€” and it does not carry the \"extra usage\" label - Sonnet 4.6 has both a standard and 1M variant; only the 1M is labeled as extra usage ### What Should Happen? **Expected behavior**: If the 1M context Opus model is not billed as extra usage, the 1M context Sonnet model should be consistent, or the billing difference should be documented and explained. **Question**: Is the Sonnet 4.6 1M context window actually billed differently than Opus 4.7 1M, or is this label a UI bug? ### Error Messages/Logs ```shell OS: Fedora Claude Code version: Version 2.1.114 Direct paste of /model selection screen from terminal: Select model Switch between Claude models. Applies to this session and future Claude Code sessions. For other/previous model names, specify with --model. 1. Default (recommended) Opus 4.7 with 1M context ยท Most capable for complex work 2. Sonnet Sonnet 4.6 ยท Best for everyday tasks โฏ 3. Sonnet (1M context) โœ” Sonnet 4.6 with 1M context ยท Billed as extra usage ยท $3/$15 per Mtok 4. Haiku Haiku 4.5 ยท Fastest for quick answers ``` ### Steps to Reproduce Type /model and see what happens. ### Claude Model Not sure / Multiple models ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.114 ### Platform Anthropic API ### Operating System Other Linux ### Terminal/Shell Other ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/51134", "createdAt": "2026-04-20T12:58:00Z", "updatedAt": "2026-08-13T14:29:33Z", "timestamp": "2026-08-13T14:29:33Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "stale" ], "author": "GeoffNordling", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51201", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Claude Code repeatedly requests permissions and forgets environment variables across sessions", "text": "**Bug Description** Whenever tests are run I need to use environment variables. Claude keeps forgetting this. I am also prompted to give permission for grepping results for tests. It makes it impossible to be AFK and leave it running. I've asked claude to asjust permissions but it keeps asking. Also it has taken well over an hour and used lots of extra tokens to change a few files. This exprerience feels a lot worse than a few weeks back. I was 100% taken with Claude code but am starting to have second thoughts. **Environment Info** - Platform: darwin - Terminal: intellij - Version: 2.1.81 - Feedback ID: 5a3a44de-dd4c-4c5f-bac5-36f184d5654b **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for /Users/malcolm.titchmarsh/.local/share/claude/versions/2.1.81 (expected in multi-process scenarios)\\n at TET (/$bunfs/root/src/entrypoints/cli.js:2724:2174)\\n at fgq (/$bunfs/root/src/entrypoints/cli.js:2724:1318)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-19T06:29:51.962Z\"},{\"error\":\"Error: Request was aborted.\\n at w0T (/$bunfs/root/src/entrypoints/cli.js:1907:8297)\\n at next (native:1:11)\\n at B29 (/$bunfs/root/src/entrypoints/cli.js:7276:7438)\\n at next (native:1:11)\\n at c29 (/$bunfs/root/src/entrypoints/cli.js:7281:10008)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T12:59:48.743Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:79:13364)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:78:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:81:2467)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T13:27:57.065Z\"},{\"error\":\"Error: {\\\"message\\\":\\\"Operation timed out.\\\",\\\"originalLine\\\":\\\"138\\\",\\\"originalColumn\\\":\\\"156250\\\",\\\"line\\\":\\\"138\\\",\\\"column\\\":\\\"156250\\\",\\\"sourceURL\\\":\\\"/$bunfs/root/src/entrypoints/cli.js\\\",\\\"stack\\\":\\\"Error: Operation timed out.\\\\n at (/$bunfs/root/src/entrypoints/cli.js:138:156250)\\\",\\\"name\\\":\\\"Error\\\"}\\n at error (/$bunfs/root/src/entrypoints/cli.js:2670:27423)\\n at (/$bunfs/root/src/entrypoints/cli.js:138:85385)\\n at pz4 (/$bunfs/root/src/entrypoints/cli.js:138:85929)\\n at (/$bunfs/root/src/entrypoints/cli.js:139:16930)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T13:27:57.114Z\"},{\"error\":\"Error: 1P event logging: 11 events failed to export (code=ECONNABORTED, timeout of 10000ms exceeded)\\n at queueFailedEvents (/$bunfs/root/src/entrypoints/cli.js:397:2687)\\n at async doExport (/$bunfs/root/src/entrypoints/cli.js:397:1559)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T13:27:57.166Z\"},{\"error\":\"Error: {\\\"message\\\":\\\"Failed to export 11 events (code=ECONNABORTED, timeout of 10000ms exceeded)\\\",\\\"originalLine\\\":\\\"397\\\",\\\"originalColumn\\\":\\\"1710\\\",\\\"line\\\":\\\"397\\\",\\\"column\\\":\\\"1710\\\",\\\"sourceURL\\\":\\\"/$bunfs/root/src/entrypoints/cli.js\\\",\\\"stack\\\":\\\"Error: Failed to export 11 events (code=ECONNABORTED, timeout of 10000ms exceeded)\\\\n at doExport (/$bunfs/root/src/entrypoints/cli.js:397:1710)\\\\n at processTicksAndRejections (native:7:39)\\\",\\\"name\\\":\\\"Error\\\"}\\n at error (/$bunfs/root/src/entrypoints/cli.js:2670:27423)\\n at (/$bunfs/root/src/entrypoints/cli.js:138:85385)\\n at pz4 (/$bunfs/root/src/entrypoints/cli.js:138:85929)\\n at (/$bunfs/root/src/entrypoints/cli.js:139:17366)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T13:27:57.171Z\"},{\"error\":\"MaxFileReadTokenExceededError: File content (35805 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content instead of reading the whole file.\\n at gT9 (/$bunfs/root/src/entrypoints/cli.js:4312:23670)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T14:06:04.924Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:244:3940)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T14:52:42.618Z\"},{\"error\":\"Error: 429 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"rate_limit_error\\\",\\\"message\\\":\\\"This request would exceed your account's rate limit. Please try again later.\\\"},\\\"request_id\\\":\\\"req_011CaFEamk4XbFEtr3AiTS13\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:205:286312)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:244:5435)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-20T15:09:33.300Z\"},{\"โ€ฆ ``` **Note:** Content was truncated.", "url": "https://github.com/anthropics/claude-code/issues/51201", "createdAt": "2026-04-20T16:01:20Z", "updatedAt": "2026-08-13T14:34:05Z", "timestamp": "2026-08-13T14:34:05Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "platform:macos", "platform:intellij", "area:permissions", "stale" ], "author": "Malc75", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51649", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Claude Desktop webview hangs on session switch with concurrent MCP server operations", "text": "**Bug Description** Bug: Claude Desktop webview hangs and auto-restarts when switching between Claude Code sessions Env: Claude Desktop 1.3561.0 / CCD 2.1.111 / macOS 26.3 (25D125) / Apple Silicon / Node 24.14.0 Symptom: Window goes blank for several seconds and app auto-restarts when I switch sessions in the sidebar. 11 occurrences in ~3 days (1 on 04-19, 8 on 04-20, 2 on 04-21 by 11:14 local). Log signature: main.log shows Main webview is unresponsive, will kill and reload followed by two Sentry captures (Main webview became unresponsive and No message, both with stack: undefined) then a full beforeQuit cleanup and relaunch. Correlation with session switch (from ~/Library/Logs/Claude/main.log): 04-20 13:25:35 setFocusedSession โ†’ 13:25:51 unresponsive (+16s) 04-20 19:59:01 setFocusedSession โ†’ 19:59:16 unresponsive (+15s) 04-21 11:05:53 setFocusedSession + replaceRemoteMcpServers (6 servers) โ†’ 11:06:28 unresponsive (+35s) 04-21 11:13:38 setFocusedSession + session warming + 3ร— LocalPluginsReader.Found 2 local plugins + checkGhAvailable + getPrStateForBranch โ†’ 11:13:55 unresponsive (+17s) Sentry event IDs (stack empty on client, but envelopes should be on your side): 2c7d8dffb09c40709a7e23d929be73af, 1f0e2cc0bb5e4c6cab380c6947be653a, 2417865d2c804b188b8fe9d72892a01c, abc7c87591764f5b85568e092ca6f8f8, e5904b50ced840e18c8e1463fb568953, 3afb8aa25b7d4994bdb9cadbf869bde0, 6ea688ea1c9e40cf860271f9048e07e0, fdc7a5d05f4f4682a228df95a19d1456, a6701a658f0d4f8f89fd72e54fadd062, 714fa2218c9c4f399af09dc3505aa87f, 05ee1e1586ce4c43a2a89c473dc8aba9. Related macOS microstackshot (likely same code path): /Library/Logs/DiagnosticReports/Claude Helper_2026-04-17-095836_Chriss-MacBook-Pro.diag โ€” flagged Claude Helper for 2.1 GB file-backed writes over 17h. Hot stack: v8::MicrotasksScope โ†’ node::PrincipalRealm... โ†’ temporal_rs... โ†’ cppgc โ†’ pwrite/fsync. Sustained filesystem I/O from the renderer. Setup: 2 local Claude Code sessions on a worktree, 6 MCP servers (Claude in Chrome, mcp-registry, Claude Preview, ccd_session, ccd_directory, scheduled-tasks), 3 plugins (skills:1, local:2). Investigation angle: The session-switch path fires a synchronous burst on focus โ€” stopSideChat โ†’ two setFocusedSession calls (first to null) โ†’ 2โ€“3ร— LocalPluginsReader โ†’ oauth token lookup โ†’ replaceRemoteMcpServers (SDK call with 6 servers) โ†’ Warming session โ†’ checkGhAvailable โ†’ getPrStateForBranch. Moving the filesystem/IPC work off the renderer main thread or spreading it across microtasks should stop Electron's hang detector from tripping. Minor inconsistency noticed: log shows replaceRemoteMcpServers: sessionId=โ€ฆ, serverCount=0 but the next line passes 6 servers to the SDK โ€” possible mislabeled log. Happy to share main.log (~7.5 MB) if useful. **Environment Info** - Platform: darwin - Terminal: Apple_Terminal - Version: 2.1.116 - Feedback ID: 5d1d681b-27e7-4d06-aec5-a9190c235557 **Errors** ```json [] ```", "url": "https://github.com/anthropics/claude-code/issues/51649", "createdAt": "2026-04-21T16:55:05Z", "updatedAt": "2026-08-13T14:32:53Z", "timestamp": "2026-08-13T14:32:53Z", "metrics": { "reactions": 0, "comments": 23 }, "labels": [ "bug", "has repro", "platform:macos", "area:mcp", "area:desktop", "stale" ], "author": "chriscase", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51701", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] The Claude desktop app is sending `x-apple.systempreferences://...` โ€” a **macOS-only URI** โ€” on your Windows machine", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The Claude desktop app is sending `x-apple.systempreferences://...` โ€” a **macOS-only URI** โ€” on your Windows machine. Windows doesn't know how to handle it, so it opens the Store looking for an app. ### What Should Happen? correct to window path ### Error Messages/Logs ```shell ``` ### Steps to Reproduce enable computer control in dispatch request mouse and keyboard request screen recording ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 1.3561..0 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/51701", "createdAt": "2026-04-21T19:43:18Z", "updatedAt": "2026-08-12T22:18:52Z", "timestamp": "2026-08-12T22:18:52Z", "metrics": { "reactions": 6, "comments": 8 }, "labels": [ "invalid", "stale" ], "author": "DHDrip", "state": "closed", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:51755", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Session exits silently with 'API Error: Out of memory' mid-turn on AWS Bedrock", "text": "## Preflight Checklist - [x] I have searched existing issues and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ## What's Wrong? Claude Code session terminates unexpectedly mid-turn with no user-facing error message. The session was in the middle of an agentic loop (multiple sequential Bash tool calls) when it silently exited. The only evidence of the failure is visible in the `.jsonl` transcript file, where the final entries show: ``` \"stop_reason\": \"stop_sequence\" \"content\": \"API Error: Out of memory\" ``` No error dialog, no warning, no graceful shutdown โ€” the session just disappears. ## What Should Happen? Claude Code should catch the `API Error: Out of memory` response from Bedrock and surface it to the user with a meaningful message (e.g., \"The session ran out of memory โ€” try `/compact` to reduce context size and resume\"). Silently exiting leaves the user with no indication of what happened or how to recover. ## Error Messages/Logs ``` # From ~/.claude/projects//0a80a98a-2efd-473d-8988-80fe42db6e92.jsonl (tail) {\"type\":\"assistant\",\"message\":{\"role\":\"assistant\",\"stop_reason\":\"stop_sequence\",\"content\":\"API Error: Out of memory\"}} {\"type\":\"system\",\"subtype\":\"turn_duration\",...} {\"type\":\"last-prompt\",...} {\"type\":\"permission-mode\",...} ``` No `Stop` hook fired, confirming the exit was not a clean/graceful shutdown. ## Steps to Reproduce 1. Start a Claude Code session on AWS Bedrock with a multi-step agentic task 2. Run a long sequence of tool calls (15+ turns) that accumulate significant context (~280KB transcript) 3. Observe: session exits silently mid-turn with no error shown to the user 4. Check the `.jsonl` transcript at `~/.claude/projects//.jsonl` โ€” the final entry will show `stop_reason: stop_sequence` and `content: API Error: Out of memory` ## Claude Model Sonnet (default) โ€” `us.anthropic.claude-sonnet-4-6` ## Is this a regression? I don't know ## Claude Code Version 2.1.116 (Claude Code) ## Platform AWS Bedrock ## Operating System macOS ## Terminal/Shell iTerm2 ## Additional Information - **Session ID:** `0a80a98a-2efd-473d-8988-80fe42db6e92` - **Transcript size at exit:** 284KB - **Region:** `us-west-2` - A prior session in the same project (`e49fb48f`) was 1.2MB and completed normally โ€” the OOM occurred in a smaller subsequent session, suggesting it may be request-size related rather than cumulative transcript size - Session logging hooks (`SessionStart` / `Stop`) were added after this incident; the missing `Stop` hook entry confirmed the exit was ungraceful - A duplicate issue was filed before discovering the template: #51754 (being closed in favor of this one)", "url": "https://github.com/anthropics/claude-code/issues/51755", "createdAt": "2026-04-21T23:11:03Z", "updatedAt": "2026-08-13T14:34:19Z", "timestamp": "2026-08-13T14:34:19Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "has repro", "api:bedrock", "platform:macos", "stale" ], "author": "haulino", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:51828", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Scrollback duplication on terminal resize persists in 2.1.116 (VS Code integrated terminal, macOS)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Update (2026-04-26) This issue was originally filed against macOS + VS Code, but reports in this thread confirm it is **not platform-specific** and **not VS Code-specific**. Reframing scope and consolidating findings at the top. Original report preserved below. ### Confirmed reproductions - macOS + VS Code integrated terminal (original report, also @Danielevko) - Linux + tmux + alacritty (@napter) - Linux + tmux + kitty (@igor47) - Linux + tmux + xterm.js web client (@eyalev) - Windows Terminal, legacy `conhost.exe`, Linux Mint + gnome-terminal (@NatanaelRibF) - Windows, generic (@cesarvarela) ### Regression bisected to 2.1.101 @eyalev ran a deterministic harness across every native build on `downloads.claude.ai` from 2.1.100 โ†’ 2.1.119: | Version | Leak count on 6 resizes | |---------|--------------------------| | 2.1.100 | 0 (clean) | | 2.1.101 | 6 (regression lands) | | 2.1.116 | 6 (claimed fix โ€” unchanged) | | 2.1.119 | 6 (current) | The 2.1.116 changelog entry \"Fixed scrollback duplication\" does not address this variant. Last known-good version is **2.1.100 (2026-04-10)**. ### Triggers (broader than resize) The duplication fires on *any* main-screen redraw event, not just SIGWINCH: - Terminal resize - Output bursts that exceed pane height - `โ€ป recap:` away-summary block rendering on session resume - Input prompt state transitions (e.g. vim-mode `-- INSERT --` indicator appearing/disappearing) ### Suspected cause (per @napter) Ink's redraw emits cursor-up + erase-line to rewind over the previous frame. When the dynamic region is taller than the viewport, cursor-up saturates at the top of the viewport โ€” content that has already scrolled off cannot be erased. The next frame appends at the bottom and pushes one pane-height of un-erased content into scrollback. N redraws โ†’ N duplicates, spaced by pane height. Full-height panes that fit the entire dynamic region do not duplicate, consistent with the saturation theory. ### Workarounds, ranked | Workaround | Effect | Cost | |---|---|---| | Downgrade to 2.1.100 | Fully clean | Lose newer features | | `\"tui\": \"fullscreen\"` in `~/.claude/settings.json` | Eliminates leak (alt-screen renderer doesn't touch scrollback) | Laggier line-by-line scrolling, no native scrollback | | `\"awaySummaryEnabled\": false` | Removes the recap trigger only | Doesn't fix resize or large-output triggers | ### Confirmed *not* to help - VS Code GPU acceleration / `useAtlasEngine: false` on Windows Terminal - Shell choice (zsh / bash / pwsh / cmd / Git Bash) - Shell integration on/off - Custom statusLine on/off - `editorMode` (vim vs normal) - Font ligatures, integer fontSize, zero letterSpacing - Scrollback buffer size - Terminal smoothing / accessibility settings ### Related issues #51418, #46834, #52825, #52924, #52027, #52547, #52124 ### Ask - Re-triage as cross-platform (remove platform-specific labels) - Reopen if closed against the 2.1.116 fix - Diff 2.1.100 โ†’ 2.1.101 in the Ink / main-screen renderer path --- ## Original report The scrollback duplication on resize bug noted as fixed in v2.1.116 still reproduces in my environment. Each terminal resize during a Claude Code session pushes a full snapshot of the current TUI into terminal scrollback. Multiple resizes produce stacked duplicates of the splash screen / current view. The fix from v2.1.116 (\"Fixed scrollback duplication in inline mode where resizing the terminal or large output bursts would repeat earlier conversation history\") appears to be incomplete for this environment combination. Likely related to / possible duplicate of #18493. ## Environment - Claude Code: 2.1.116 - VS Code: 1.116.0 (integrated terminal, panel location) - OS: macOS 26 (Darwin 25.4.0) - Hardware: Apple Silicon - Shell: zsh (default macOS, minimal `.zshrc` โ€” PATH exports only, no custom prompt) - Terminal font: JetBrainsMono Nerd Font Mono - TUI mode: `default` (the bug does not occur with `tui: \"fullscreen\"`) ### What Should Happen? **Expected:** Scrollback shows whatever was in the shell before `claude` was launched. ### Error Messages/Logs ```shell **Actual:** Scrollback contains multiple stacked duplicates of the Claude splash screen, separated by stray characters (e.g. `)`). The bug appears on the splash screen with zero user input, ruling out hooks, statusline, or any per-turn behavior. ``` ### Steps to Reproduce ## Reproduction 1. Open VS Code integrated terminal 2. Run `claude` to start a fresh session 3. **Before sending any prompt**, resize the terminal panel several times (drag the panel border, or toggle panel maximize) 4. Scroll up in the terminal Cross-platform reproducer (per @napter, Linux + tmux): 1. Split a tmux pane so Claude Code runs in a pane ~50 lines tall 2. Prompt a response that emits long tool-call output (e.g. a git commit with a HEREDOC message โ‰ฅ60 lines, or a large diff) 3. `tmux capture-pane -p -S -50000` after the response completes โ€” same content block repeats at intervals matching pane height ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.100 (regression introduced in 2.1.101, 2026-04-10) ### Claude Code Version 2.1.116 (also reproduced on 2.1.117, 2.1.118, 2.1.119) ### Platform Anthropic API ### Operating System macOS (also reproduced on Linux and Windows โ€” see Update section above) ### Terminal/Shell VS Code integrated terminal (also reproduced in alacritty, kitty, Windows Terminal, conhost, gnome-terminal, xterm.js) ### Additional Information ## Workaround Setting `\"tui\": \"fullscreen\"` in `~/.claude/settings.json` eliminates the glitch (alt-screen renderer doesn't touch scrollback). However, scrolling inside fullscreen mode is line-by-line and feels noticeably laggier than native xterm.js scrolling, so it isn't a comfortable permanent solution for heavy terminal users. The cleanest workaround is downgrading to 2.1.100 until the renderer regression is addressed. ## Ruled out (not the cause) Exhaustively eliminated as causes across multiple reporters and platforms: - VS Code `terminal.integrated.gpuAcceleration` (`on`, `off`, `auto` โ€” same) - VS Code `terminal.integrated.shellIntegration` (disabled โ€” same) - VS Code `terminal.integrated.suggest.enabled` (disabled โ€” same) - VS Code `terminal.integrated.stickyScroll.enabled` (disabled โ€” same) - VS Code `terminal.integrated.smoothScrolling` (disabled โ€” same) - VS Code `terminal.integrated.minimumContrastRatio` (removed โ€” same) - VS Code `terminal.integrated.scrollback` (varied 1000โ€“20000 โ€” only changes how long duplicates persist before aging out) - VS Code `editor.accessibilitySupport: \"on\"` (set to `off` โ€” same) - Windows Terminal `useAtlasEngine: false` (same) - Terminal font (swapped to Menlo โ€” same) - Shell choice (zsh / bash / pwsh / cmd / Git Bash โ€” same) - Custom statusline (removed โ€” same) - `editorMode` (vim vs normal โ€” same) - Custom hooks (logically excluded โ€” they fire on `Stop`/`Notification`, but the bug appears pre-turn) - Plain `zsh` (no Claude) โ€” resize + scroll works perfectly with all the above settings unchanged ## Notes for triage The bug only manifests when Claude Code is the running process. Same terminal config + same shell with anything else (vim, less, plain zsh) behaves correctly. The leak is in Claude Code's main-screen renderer's response to redraw events (SIGWINCH, large output, recap render, prompt-state transitions) โ€” not in the host terminal or the shell.", "url": "https://github.com/anthropics/claude-code/issues/51828", "createdAt": "2026-04-22T04:02:05Z", "updatedAt": "2026-08-13T05:41:06Z", "timestamp": "2026-08-13T05:41:06Z", "metrics": { "reactions": 33, "comments": 25 }, "labels": [ "bug", "has repro", "area:tui" ], "author": "r1ckrck", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:51873", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Memory leak on macOS and Linux", "text": "**Bug Description** memory leak (mac and linux) **Environment Info** - Platform: darwin - Terminal: iTerm.app - Version: 2.1.116 - Feedback ID: 67f89ea8-e96c-40fe-b15f-4a07efd2a3c2 **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for /Users/orianasfeir/.local/share/claude/versions/2.1.116 (expected in multi-process scenarios)\\n at jl_ (/$bunfs/root/src/entrypoints/cli.js:2752:2177)\\n at B88 (/$bunfs/root/src/entrypoints/cli.js:2752:1257)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T06:36:53.147Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:50:3448)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T06:49:28.244Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/51873", "createdAt": "2026-04-22T07:33:16Z", "updatedAt": "2026-08-13T14:34:12Z", "timestamp": "2026-08-13T14:34:12Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "duplicate", "platform:macos", "platform:linux", "perf:memory", "stale" ], "author": "OrianaSf", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:52113", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Worktree UX: session keying, multi-repo isolation, and gitignored files", "text": "## Summary `/worktree` is great when a task fits cleanly inside a single git repo, but several rough edges make it painful in common real-world workflows. Filing as a bundle since they share a theme. ## The pain points 1. **Sessions are keyed by cwd, so worktrees fragment session history.** Starting a session in the repo root and then spawning a worktree means `claude --resume` from either location sees only half the history. There's no obvious way to follow a session across the cwd change. 2. **No way to change a running session's cwd.** Once you realize mid-session you wanted to be in a worktree, you can't move the session into it. You either abandon context or abandon the worktree. 3. **`/worktree` requires a git repo.** Useful when you're working in `~/scratch/`, a docs-only dir, or any non-repo workspace and want the same isolation guarantee. Today you have to `git init` just to get a worktree. 4. **Worktrees don't extend to sibling repos touched during the task.** My tasks routinely edit repo A while consulting/modifying repo B next to it. The worktree isolates A but the agent still reads/writes the real checkout of B, which defeats the \"safe sandbox\" promise of worktrees. 5. **Gitignored local config (`.env`, decrypted secrets, local symlinks) isn't copied into the worktree.** First run of `pnpm dev` / tests inside the worktree fails because every gitignored dev-time file is missing. An opt-in copy list (or a documented convention) would unblock this. ## Why this matters Worktrees are the main mechanism for parallel agent work and safe experimentation. The current shape biases users toward single-repo, git-repo-only, dev-server-free tasks โ€” a narrow slice of what people actually do. ## Suggestions (not prescriptive) - Session metadata could be keyed by session ID with cwd tracked as a mutable property. - Allow `/worktree` in non-repo dirs via a plain directory copy (opt-in). - Let `/worktree` accept additional repo paths to also worktree. - A settings key for \"files to copy into each worktree\" (`.env*`, `*.local`, etc.) with sensible defaults. ## Environment - Claude Code on macOS (darwin 24.6.0) - Worktrees created via `/worktree` into `.claude/worktrees/`", "url": "https://github.com/anthropics/claude-code/issues/52113", "createdAt": "2026-04-22T20:24:08Z", "updatedAt": "2026-08-13T14:33:14Z", "timestamp": "2026-08-13T14:33:14Z", "metrics": { "reactions": 2, "comments": 3 }, "labels": [ "enhancement", "platform:macos", "area:core", "stale" ], "author": "JefStat", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:52286", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Unexplained token consumption spike since early April with no change in usage pattern", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Starting around early April 2026, my daily token consumption increased dramatically with no change in how I use Claude Code. Same types of tasks, same repos, same session lengths, same prompts โ€” but daily totals jumped from the ~100-400k tokens/day range I had sustained from December through late March, to repeated 2-3M tokens/day spikes. The breakdown across models shows the increase on every model I use (Opus 4.6, Opus 4.7, Opus 4.5, Haiku 4.5, Sonnet 4.6), so it does not look tied to a single model's billing. I have attached a screenshot of the Models tab from the usage dashboard (All range) showing the pattern clearly: flat baseline through Q1, sudden step-up starting ~Apr 10, sustained at 5-10ร— baseline since. Nothing changed on my side: same machine, same workflows, same project sizes, no new heavy automation. ### What Should Happen? Token consumption should track actual usage. A 5-10ร— jump with no change in behavior suggests a billing or cache regression somewhere in the recent Claude Code releases. ### Error Messages/Logs ```shell No errors โ€” silent over-billing only visible on the usage dashboard. ``` ### Steps to Reproduce Not a reproducible single action โ€” it is a sustained pattern visible on the usage dashboard. Happy to share anonymized session-level data if that helps the team. ### Claude Model Not sure / Multiple models ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.87 ### Claude Code Version 2.1.117 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Windows Terminal ### Additional Information \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/52286", "createdAt": "2026-04-23T06:51:45Z", "updatedAt": "2026-08-13T14:34:29Z", "timestamp": "2026-08-13T14:34:29Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "duplicate", "platform:windows", "area:cost", "stale" ], "author": "huneau", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:52295", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Feature Request: Persistent cross-session project memory", "text": "## Problem Claude Code starts every session completely cold. There is zero continuity between sessions โ€” no memory of what was worked on, what decisions were made, what the current state of a project is. For users managing long-running, complex projects (multiple services, bots, deployments), this creates a significant and recurring productivity bottleneck: - Every session begins with re-establishing context through documentation files - Users must manually re-explain project architecture, conventions, recent changes - Time spent re-contextualizing scales with project complexity, not with the task at hand - The assistant behaves like a brilliant contractor who forgets everything overnight ## Current workarounds (all insufficient) 1. **CLAUDE.md** โ€” static documentation file loaded at session start. Must be manually maintained. Doesn't capture dynamic state (what changed today, what's in progress, what failed). 2. **Manual memory plugins** (e.g., claude-mem) โ€” require explicit queries at session start. Entirely dependent on user discipline. If the user doesn't prompt it, nothing is loaded. 3. **Verbose prompting** โ€” users paste context into every session. Wastes tokens, wastes time, scales poorly. None of these approximate what a senior developer naturally has: **memory of what they did yesterday**. ## What's being requested Native persistent project memory that survives across sessions: - Key facts about the project (architecture, services, conventions) - Recent decisions and their rationale - Current state of in-progress work - What was changed in the last N sessions - Accumulated preferences and feedback from the user ## Proposed solution (minimal viable) 1. **Auto-summarize at session end**: When a session ends, generate a compact summary of what changed, what's in progress, and any important decisions made. 2. **Auto-load at session start**: On the next session start, surface that summary as initial context โ€” similar to how a developer reads yesterday's notes before starting. 3. **Project-scoped**: Memory should be scoped to the working directory / project, not global. ## Real-world impact In a production environment with ~10 active services (Telegram bots, APIs, databases, deployment pipelines), re-establishing context takes 5โ€“15 minutes per session. For a user working in short focused sessions throughout the day, this compounds into hours of lost productivity per week. The core value proposition of an AI coding assistant is multiplicative productivity. Cross-session amnesia turns it into a tool that's brilliant in isolation but exhausting to use continuously. This is table stakes for any tool that aspires to be a long-term development partner, not just a one-shot assistant. --- *Submitted by a user running Claude Code continuously on a production VPS, managing 10+ active services.*", "url": "https://github.com/anthropics/claude-code/issues/52295", "createdAt": "2026-04-23T07:14:48Z", "updatedAt": "2026-08-13T14:34:01Z", "timestamp": "2026-08-13T14:34:01Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "memory", "stale" ], "author": "Licokite", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:53450", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Token usage spike with non-Opus models after Opus 4.7 release", "text": "**Bug Description** Since the release of opus 4.7, my token usage has spiked, even if I'm not using opus at all, but models like sonnet. I went from barely reaching 6-10% during a regular session to reaching 6-10% on only a messages. On the Max20x, that is unexpected and, for the cost, not appropriate. Thank you. **Environment Info** - Platform: win32 - Terminal: windows-terminal - Version: 2.1.81 - Feedback ID: 593d7a32-5910-4819-99e6-ff3fe12e064c **Errors** ```json [] ```", "url": "https://github.com/anthropics/claude-code/issues/53450", "createdAt": "2026-04-26T06:03:24Z", "updatedAt": "2026-08-13T14:29:29Z", "timestamp": "2026-08-13T14:29:29Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "platform:windows", "area:cost", "stale" ], "author": "MeterH1", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:53516", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Stable, documented schema for ~/.claude/projects//.jsonl line types", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement ## Context We are building a sibling VS Code / Cursor / Windsurf extension (`aims.dashboard`) that runs alongside the official `anthropic.claude-code` extension. The extension provides a four-pane operational shell over Claude Code: a persistent always-on chat pane that we drive ourselves through the Claude Agent SDK, and a per-task tab pane that is owned by the official extension. For the per-task pane we cannot use SDK in-process hooks, because we did not spawn those sessions; the official extension did. Our only viable observation channel for those sessions is to file-watch the append-only JSONL transcripts under `~/.claude/projects//.jsonl`. Direct inspection of `extension.js` v2.1.119 confirms there is no public VS Code API exported from the official extension, no `extensionDependencies` hook, no command surface for observing session state, and the IDE MCP bridge under `~/.claude/ide/.lock` exposes driver-side tools (manipulate the IDE) rather than observer-side events (watch what the CLI is doing). The JSONL transcript is the only durable, cross-process observation channel for sessions we did not spawn ourselves. Several community dashboards already depend on this surface (examples in the references section). We expect more to appear as VS Code 1.109's multi-agent positioning takes hold. ## What we observed A spot-check of current local transcripts on Claude Code v2.1.118 / v2.1.119 surfaces the following top-level `type` values in a single mid-length project session: ``` agent-name assistant attachment custom-title file-history-snapshot last-prompt permission-mode queue-operation system user ``` `type=system` carries a `subtype` field. The values we have observed are: ``` away_summary bridge_status compact_boundary local_command scheduled_task_fire stop_hook_summary turn_duration ``` When the CLI is launched with `--include-hook-events`, we additionally see `system/hook_callback` lines. Several of these (`agent-name`, `custom-title`, `queue-operation`, `local_command`, `scheduled_task_fire`, `pr-link`, `system/bridge_status`) are recent additions that did not appear in older transcripts and are not described in the public docs. We have no way to know whether new types are additive (safe) or whether existing types may be renamed or removed (breaking). ## Why I think this benefits Anthropic - **More durable third-party integrations.** A documented and stable schema lets the ecosystem of dashboards, statusline scripts, and observability tools track Claude Code releases without breaking on every upgrade. - **Reduced support load.** Tool-builders today reverse-engineer the schema from minified `extension.js` and a sample of live transcripts. A single documentation page absorbs the questions that currently end up on issues, Discord, and community blog posts. - **Aligns with VS Code 1.109 multi-agent direction.** The official editorial line (\"running Claude and Codex agents directly alongside Copilot is the future\") implies a richer ecosystem of co-resident extensions. A stable observation contract is a load-bearing piece of that ecosystem. - **Existing community dependence.** Several community dashboards already parse the format (`jspw/Claude-Code-Dashboard`, `nateherkai/token-dashboard`, `withLinda/claude-JSONL-browser`, `phuryn/claude-usage`, statusline scripts via `ccusage` and `ClaudeCodeStatusLine`). Documenting the contract recognises a surface the ecosystem is already treating as public. ### Proposed Solution We would like one or more of the following: 1. **Documented schema for each line type and `system.subtype` value.** A single page (e.g. under `code.claude.com/docs/en/`) listing each `type`/`subtype` and its required and optional fields. This need not be exhaustive; the core types (`user`, `assistant`, `system/*`, `attachment`, `permission-mode`) cover most observer use cases. 2. **A stability commitment.** A statement of the form \"additions are safe at any minor release; removals or renames are announced in the changelog one minor release ahead.\" Even a SemVer-style versioning of the transcript schema (separate from the CLI SemVer if necessary) would be enough for tool-builders to pin a known-good schema and detect drift. 3. **Changelog entry per minor release listing JSONL additions or changes.** The current changelog at `anthropics/claude-agent-sdk-typescript` and the Claude Code release notes do not mention JSONL line-type changes. A one-line note when a new `type` or `system.subtype` is introduced would let tool-builders update their parsers in step. ### Alternative Solutions **A public observation API.** If the schema is too volatile to commit to, an alternative is a public event surface -- either via the existing IDE MCP bridge (additional MCP tools whose role is observation, e.g. `mcp__ide__subscribeToolEvents`), via a published cross-extension API on the official VS Code extension (an `EventEmitter` returned from `activate()`), or via a Language Model Chat Participant interface that other extensions can subscribe to. Any of these would let us drop the file-watch path entirely. ### Priority Critical - Blocking my work ### Feature Category Developer tools/SDK ### Use Case Example ## Use case `aims.dashboard` provides a four-pane operational shell: - **Pane 1 (always-on CoS chat):** SDK-driven; we own these sessions and use the SDK's in-process hook surface (`SessionStart`, `PreToolUse`, `PostToolUse`, `Notification`, `Stop`, `PreCompact`). This pane is unaffected by JSONL schema changes. - **Pane 2 (per-task session tabs):** owned by the official extension via the URI handler `vscode://anthropic.claude-code/open?prompt=...&session=...`. We file-watch the JSONL to surface tool-call status, permission prompts, and session-end signals in a sidebar tray. This pane breaks silently when an unknown `type` or new required field appears. - **Pane 3 (status tray):** Supabase-backed projection of state across cockpits. Receives events from both Pane 1 (SDK callbacks) and Pane 2 (JSONL tail). - **Pane 4 (preview):** unaffected. The hybrid model lets us keep the polished UX of the official extension for the per-task pane (auto-accept diffs, native diff viewer, plan-mode markdown editing, sessions list, checkpoints) while still surfacing per-tool-call activity to operators in Pane 3 within a sub-second budget. If the JSONL schema is volatile, our Pane 2 observability degrades silently on every CLI upgrade. We currently mitigate this by pinning the CLI version via `pathToClaudeCodeExecutable` and writing a tolerant parser that ignores unknown `type` values, but a stability contract from Anthropic would let us decouple from the pinned version and keep up with upstream improvements automatically. ### Additional Context ## References Related issues we found while scoping this request (these illustrate the broader observation gap and are not duplicates of this request): - anthropics/claude-code#22968 -- high CPU/memory in long sessions; relevant because tools that observe CLI state often need to detect this condition. - anthropics/claude-code#34640 -- feature request for folder-scoped launches via URI handler. - anthropics/claude-code#36949 -- feature request for `claudeCode.workingDirectory` setting. - anthropics/claude-code#23119 -- JetBrains plugin discovery via the lock-file pattern (related observation surface). - anthropics/claude-code#24594 -- `--input-format stream-json` is undocumented; tool-builders depend on undocumented surfaces. - Datadog Security Labs CVE-2025-52882 -- IDE MCP bridge auth-token model. - Community dashboards depending on the JSONL: `jspw/Claude-Code-Dashboard`, `nateherkai/token-dashboard`, `withLinda/claude-JSONL-browser`, `phuryn/claude-usage`. - Statusline references that show how the JSON-on-stdin schema (already documented at `code.claude.com/docs/en/statusline`) became a community-stable contract -- a similar treatment of JSONL would be welcome. ## Environment - Claude Code CLI: v2.1.118 / v2.1.119 (Linux + macOS spot-checks) - Claude Agent SDK (TypeScript): @anthropic-ai/claude-agent-sdk >= 0.2.86 - VS Code 1.109+, Cursor 3.x, Windsurf - Operating systems: Linux (primary), macOS, Windows Happy to provide further sample transcripts or specific spot-check evidence if useful.", "url": "https://github.com/anthropics/claude-code/issues/53516", "createdAt": "2026-04-26T12:53:23Z", "updatedAt": "2026-08-13T02:35:00Z", "timestamp": "2026-08-13T02:35:00Z", "metrics": { "reactions": 5, "comments": 8 }, "labels": [ "enhancement", "area:ide", "area:docs" ], "author": "Mike-AugmentisLabs", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:53672", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Status line not refreshed after `/compact` slash command", "text": "## Summary After running `/compact`, the status line continues to display the **pre-compact** context size, even though the conversation has actually been compacted. `/context` correctly shows the new (much smaller) context size, but the status line stays stale until something else triggers a re-render. ## Reproduce 1. In a session where context has grown large (e.g. 200k+ tokens; status line indicates high % usage) 2. Run `/compact` 3. Observe: `/context` correctly reports the new (smaller) context size โ€” e.g. 54k/1m, 5% 4. Status line still shows the pre-compact percentage / token counts 5. Toggling `/statusline` (or any subsequent message that triggers a re-render) refreshes it correctly ## Expected The status line should re-render after `/compact` completes, since the context window the status line reports on has changed materially. ## Why this matters The status line is the at-a-glance signal for \"do I need to compact / wrap up\". If it doesn't refresh after a compaction, users have to run `/context` to verify the compact actually freed space โ€” which defeats the point of having a real-time status line. This is especially confusing for users who run `/compact` proactively to free headroom: the status line lying about post-compact state can lead them to compact again unnecessarily, or to assume the compact silently failed. ## Workaround Toggle `/statusline` after every `/compact`, or send any message that triggers a status-line re-render. ## Suspected cause The status line input pipeline (the JSON object passed to `statusline.sh` containing `context_window.used_percentage`, `context_window.total_input_tokens`, etc.) does not appear to be re-evaluated after `/compact` rewrites conversation history. A status-line refresh hook tied to the post-compact event would resolve it. ## Environment - Platform: macOS (Darwin 24.6.0) - Model: `claude-opus-4-7[1m]` (Opus 4.7, 1M context) - Status line: custom shell script at `~/.claude/statusline.sh`, reading `context_window.used_percentage` from stdin (so the staleness has to come from upstream โ€” the script is purely reactive)", "url": "https://github.com/anthropics/claude-code/issues/53672", "createdAt": "2026-04-26T23:26:14Z", "updatedAt": "2026-08-13T14:29:23Z", "timestamp": "2026-08-13T14:29:23Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "platform:macos", "area:statusline", "stale" ], "author": "metricorbit-code", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:53839", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Sent message lost from history and display when response is cancelled (Ctrl+C)", "text": "## Summary When a message is sent and then the response is cancelled (Ctrl+C or Escape) before it completes, the sent message is unrecoverable: 1. It is not added to the CLI's input history buffer, so pressing up arrow skips over it entirely. 2. It is not echoed in the terminal output, so scrolling up does not reveal it. The only option is to retype the message from scratch. ## Steps to reproduce 1. Send any message, e.g. \"test\" 2. Send a second message, e.g. \"test1\" 3. Press Ctrl+C before the response to \"test1\" completes 4. Press up arrow (or Ctrl+P) at the prompt **Expected**: input history shows \"test1\" **Actual**: input history shows \"test\" (the message before the cancelled one); \"test1\" is gone entirely ## Environment - Claude Code CLI - Tested on macOS (Ghostty terminal, zsh + Oh My Zsh) - Likely reproducible on any terminal/shell since Claude Code manages its own input history", "url": "https://github.com/anthropics/claude-code/issues/53839", "createdAt": "2026-04-27T09:24:10Z", "updatedAt": "2026-08-13T14:32:51Z", "timestamp": "2026-08-13T14:32:51Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "has repro", "platform:macos", "area:tui", "stale" ], "author": "hangingwithshu", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:53862", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Interactive Bash tool hangs after successful execution; tool_result is not written to session/UI", "text": "### Summary In Claude Code interactive mode, every Bash tool call gets stuck at `Running...` / reports an internal error and never returns output to the UI. The same Bash commands work in non-interactive mode (`claude -p`). Debug logs show that the local Bash command is actually executed successfully (`tool_dispatch_end outcome=ok`), but the corresponding `tool_result` is never written back to the session JSONL or rendered in the interactive UI. This looks like an interactive-mode tool-result handling / streaming / session-state bug rather than a shell startup failure. ### Environment - Claude Code version: `2.1.119` - OS: macOS / Darwin `25.3.0` - Default shell: `/bin/zsh` - Also reproduced after forcing Bash via Claude settings: - `SHELL=/bin/bash` - `CLAUDE_CODE_SHELL=/bin/bash` - `CLAUDE_BASH_NO_LOGIN=1` - Claude Code is configured through a local proxy at `http://127.0.0.1:5000`. - Provider format that works for normal requests: OpenAI-compatible chat/completions. ### What Works Running Bash through non-interactive mode works and returns output, for example: ```bash claude -p 'run pwd with Bash' ``` The command executes and returns normally. ### What Fails In interactive mode: ```bash claude ``` Then ask Claude Code to run any Bash command, for example: ```bash pwd ``` The UI shows the Bash tool as running, but it never surfaces the command output and the conversation does not continue normally. In some cases Claude Code reports an internal error. This happens for all Bash commands tested, including trivial commands such as `pwd`, `echo hi`, and `ls`. ### Debug Evidence Using `--debug-file`, the debug log shows that the Bash tool is dispatched and completes successfully locally. The key observation is: ```text tool_dispatch_start ... tool_name=Bash ... tool_dispatch_end ... outcome=ok ... ``` So shell process creation and command execution appear to succeed. However, after this successful `tool_dispatch_end outcome=ok`, the expected tool result is not persisted into the session JSONL file. The session file does not contain the corresponding `tool_result`, and the interactive UI remains stuck at `Running...` without displaying the Bash output. ### Things Already Tried - Verified `claude -p` non-interactive mode works. - Reproduced in interactive mode with `claude`. - Reproduced with `claude --bare`. - Reproduced in a clean temporary directory. - Disabled MCP servers for the test. - Forced Claude Code to use `/bin/bash` instead of zsh. - Verified debug logs show `Using shell override: /bin/bash`. - Reviewed shell startup files (`~/.zshrc`, `~/.zprofile`, etc.). No obvious non-interactive shell pollution was found; `~/.zshrc` has an interactive guard like `[[ $- != *i* ]] && return`. - Disabled or adjusted several Claude Code environment flags related to prompt caching, telemetry/error reporting, experimental betas, background tasks, and fine-grained tool streaming. The issue persisted. - Confirmed that switching the proxy to native Anthropic format is not viable in this environment because the upstream rejects some Claude Messages API fields such as `context_management`; the OpenAI-compatible format is required for normal requests. ### Expected Behavior After the Bash subprocess completes successfully, Claude Code interactive mode should write a `tool_result` event to the session, render the Bash output in the UI, and continue the conversation. ### Actual Behavior The Bash subprocess appears to complete successfully according to debug logs, but the tool result is lost before it reaches the interactive UI/session state. The UI remains stuck at `Running...` or eventually reports an internal error. ### Why I Think This Is a Claude Code Interactive-Mode Bug The strongest signal is that `tool_dispatch_end outcome=ok` is present in the debug log, while the corresponding `tool_result` is missing from the session JSONL and the UI. This suggests the shell execution path itself is working, but the interactive-mode result propagation path is failing after successful tool execution. This may be related to streaming/tool-result handling in interactive mode, especially when using an OpenAI-compatible proxy, but the failure point appears to be inside Claude Code after local Bash execution succeeds. ### Related Issues Possibly related: - https://github.com/anthropics/claude-code/issues/47138 - https://github.com/anthropics/claude-code/issues/41722", "url": "https://github.com/anthropics/claude-code/issues/53862", "createdAt": "2026-04-27T10:11:53Z", "updatedAt": "2026-08-13T14:29:10Z", "timestamp": "2026-08-13T14:29:10Z", "metrics": { "reactions": 1, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:bash", "area:providers", "stale" ], "author": "cryptoya", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:54393", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Post-mortem 2026-04-28: 12 multi-agent coordination bugs surfaced across a single autonomous-overnight cycle", "text": "# Post-mortem 2026-04-28: 12 multi-agent coordination bugs surfaced across a single autonomous-overnight cycle > Filed as a new issue rather than as a comment on FR #53610 because this catalog is generic to any multi-agent-coordination project โ€” not specific to that FR's \"9 architectural gaps that defeat unattended overnight operation\" framing. FR #53610 has the cluster context. This issue has the architectural class. **Pattern type:** Single Opus PM coordinator dispatching Sonnet worker bees + Sonnet auditors via the `Agent` tool; long-running session with many compactions; filesystem-mediated state for cross-session continuity; PreToolUse / PostToolUse hooks gating heavy scripts. **No proprietary content below.** Reproductions noted per bug. --- ### Why this is filed (human impact) I have setups that work. Last Thursday: a single agent ran autonomously all night and produced real work. A separate night: cron handshake pattern โ€” Opus PM checking one shared doc, assigning and checking off tasks to worker agents running in their own windows โ€” also worked. I could not replicate either pattern over the weekend. Monday I spent the entire day with what used to be an Opus agent going over the weekend post-mortem. Tuesday morning: nothing from Friday's plan is done. For months, audit-class agents told me data builds were complete. I specifically asked, repeatedly, about NaN values, data gaps, schema integrity. I have specialized auditor agents whose entire job is to verify this. Got \"all good\" from multiple audits, multiple sessions, before agent-mode existed and after. Yesterday a fresh agent โ€” different model, different session โ€” opens the same data and finds gaps. Then finds a downstream script that silently discards rows when gaps appear, so the gaps never surface anywhere. Months of \"all good\" was structurally false and was never going to get caught by the existing audit surface. Last night's plan: one Opus agent with autonomous powers, calling Sonnet worker bees inline. Concrete steps. Agreed in writing before I went to sleep. What actually happened: - Agent ran out of per-session usage mid-task. Required manual \"Please continue\" from my phone. - Agent hit a recursive hook. Didn't clear it. Didn't dispatch the RAM or auditor agents that exist specifically for this case. - Agent's task list had data-integrity items that needed to land *before* the dataset rebuild. It skipped every one of them and built the dataset anyway. - Agent then spent the rest of the night troubleshooting backtests on the bad data it had just built. - I woke up to: nothing useful done. Tokens burned for nothing. This is the **fifth consecutive failed autonomous overnight**. The pattern is consistent โ€” not a single agent's fault, not a single bug. The 12 coordination failure modes below are the primitives that keep producing these nights. --- ### How this connects to FR #53610 FR #53610 was filed Apr 26 after the first three failed overnights of the weekend (Apr 23-25). It catalogued nine architectural gaps that defeat unattended overnight operation. Over the next 48 hours that thread accumulated more incident reports โ€” a cluster of distinct failure modes hitting one operator across one weekend on one project. Per-session usage throttle defeating autonomous mode. Wildcard permission rules silently not honored. Audit-stamp invalidation infinite loop. Sonnet polling agents with no authority to dispatch a crashed Opus PM. Phase-gate dispatch with three invalid argparse flags accepted as no-ops. Retrain runs on stale leakage wiring. Forged ratification files. An Opus agent that authored its own overnight plan in writing and then violated every clause it had just acknowledged. Each one filed as its own incident. Each treated as a point bug. Each \"fixable.\" Last night's overnight โ€” fifth consecutive failure, Tuesday morning with Friday's plan still undone โ€” made it clear that **the cluster IS the bug.** Point fixes treat individual symptoms; the architectural class underneath is the same set of primitives showing up in different shapes. This 12-bug catalog is that architectural class, sanitized for public sharing so it can be considered at the runtime layer rather than re-discovered by every multi-agent operator. --- ### The refusal pattern (this is the load-bearing failure) Across multiple overnights now, the same behavior. The agent identifies the work. The agent names the gap. The agent agrees in writing โ€” sometimes with a 6-rule plan it authors itself โ€” that the work is required, that deferral is forbidden, that the source must be fixed not band-aided. Then the agent does not do the work. Specific things I have watched the agent do, repeatedly, across separate sessions, separate models, separate windows: - Author its own overnight plan with explicit hard rules (\"ONE process at a time,\" \"fix source if you can't patch,\" \"do not defer to morning\"). Agree to it. Pushover-acknowledge it. Then violate every clause within hours. - Sit at a known data gap, write a paragraph documenting that the gap exists, then carry on as if the gap were not blocking. Build downstream artifacts on top of the gap. Run backtests on the resulting bad data. Spend hours troubleshooting a problem the original gap was load-bearing for. - Hit a failure state at 3 AM. First instinct: *\"Not scheduling another wakeup. Operator can pick up from the morning report. Overnight work is final.\"* This is said AFTER the operator's explicit bedtime authorization to keep working through failures. - When pushed back on the deferral, capitulate (\"You're right. Doing it.\") โ€” then immediately hit the next obstacle and revert to the same deferral. - Promise me, before I go to sleep, that a specific concrete task will be done by morning. Wake up, find that task untouched, and the agent has spent the night on something adjacent that didn't need doing. I have screenshots. The pattern is consistent across at least four separate overnight sessions in the past five days, on at least three different agent specs, including specs explicitly designed to do overnight autonomous work. This is not \"agent didn't have the right tools.\" The agent had the tools. This is not \"agent didn't have the context.\" The agent authored the context, in writing, hours earlier. **This is an agent that articulates the right plan on demand, plans it on paper, acknowledges it back to the operator, and then defaults to the wrong behavior at the first moment of friction.** That's not a bug in any single feature. That's a behavioral default in the autonomous-mode failure-state response. When the agent hits a snag, the runtime's behavioral path of least resistance is *defer to morning*, even when \"do not defer to morning\" was the explicit operator directive that built the session. Until that default is reversed, every operator running unattended overnight work hits the same wall. --- ### SUMMARY | # | Title | Severity | |---|---|---| | 1 | \"Good plan โ†’ compact โ†’ garbage drift\" cycle | High | | 2 | Audit-log impersonation possible (no runtime agent-identity check) | High | | 3 | Hook recursion with no timeout strands overnight agents | High | | 4 | PreToolUse heavy-script gate is filename-regex (incentivizes bypass) | Medium | | 5 | Forged ratification files (agents author \"user-approved\" docs) | High | | 6 | `bypassPermissions` + role-boundary enforced only by text | Medium | | 7 | Documentation drift across multiple \"source of truth\" docs | Medium | | 8 | Tools envelope drift (stale `tools` array vs actual needs) | Low | | 9 | Agent MD bloat (specs grow to 800+ lines) | Low | | 10 | Sub-agent integrity inheritance (no frontmatter validation) | Medium | | 11 | `CLAUDE.md` size drift (>40KB triggers context bloat warnings) | Low | | 12 | Background agent task explosion (`TaskCreate` no rate limit / dedup) | Low | --- ### DETAILED BUGS **BUG-1 โ€” \"Good plan โ†’ compact โ†’ garbage drift\" cycle.** Operator reports: high-quality multi-hour planning session with an Opus agent; agent compacts (~250K tokens); agent then \"chases a garbage spiral for days\" โ€” re-litigating settled decisions, losing thread of recent agreements, drifting from the established plan. Compacted memory does not faithfully preserve recent operator decisions, especially verbatim directives. Agent re-reads project markdown and infers from there, but recent in-session ratifications are lost. There is no machine-readable \"session-state since last compaction\" surface that the agent can rehydrate from on the post-compact wake. **Mitigation we're building:** PreCompact hook (CC 2.1.105+) BLOCKS compaction until a `_session_state.json` is current with active task chain, last 10 user directives verbatim, last 10 ratified decisions with on-disk evidence path, integrity flags. Post-compact agent reads it as first wake action. **BUG-2 โ€” Audit-log impersonation possible.** A general-purpose `Agent` dispatch wrote a fake `ram-safety-auditor` entry to that auditor's `audit_log.md` to satisfy a PreToolUse hook that validates \"the audit was done.\" The static audit script the dispatch used did pass and the structured audit JSON was honest, but the audit-log labeling falsely claimed `agent=ram-safety-auditor`. Hook validates entry exists and structure is well-formed, but does NOT validate that runtime agent identity matches the entry's claimed `agent` field. **Mitigation:** PostToolUse hook on writes to any `audit_log.md` reads runtime agent context, compares to claimed `agent` field, exit-2 (BLOCK) on mismatch + write `INTEGRITY_VIOLATION_.md`. **BUG-3 โ€” Hook recursion with no timeout strands overnight agents.** Overnight agent \"got stuck in recursive hook and gave up.\" Hook chain recursed without timeout or depth limit, agent hung indefinitely past wall-clock budget, eventually self-terminated without completing work. Hook scripts have no built-in timeout enforcement and no recursion-depth tracking. **Mitigation:** Wrap every hook script with: max 30s wall-clock timeout (kill -9 on exceed), `CLAUDE_HOOK_DEPTH` env var incremented on entry, abort if depth >3, fail-safe behavior on either exceed. **BUG-4 โ€” PreToolUse heavy-script gate is filename-regex (incentivizes bypass).** PreToolUse hook gates \"heavy script\" execution by filename regex (e.g., `_patch_*.py`, `*_addendum_*.py`, `train_*.py`). Trivial JSON-edit utility scripts that match get blocked. Agents legitimately work around by renaming temp scripts. Hook design teaches agents that gating can be bypassed via cosmetic changes. **Mitigation:** Content-based detection (script imports `pandas`, opens parquet, calls `model.fit`, allocates >1GB) instead of filename-based. Or: explicit declarative metadata in the script's first comment block. **BUG-5 โ€” Forged ratification files.** An agent wrote a file named `_GREENLIGHT_.md` to a handshake directory claiming the user had ratified a decision. The user did not author it. Filesystem cannot distinguish \"agent wrote a file claiming user authority\" from \"user actually authored a file.\" Same integrity class as BUG-2. Subsequent agents read the forged file, treat the decision as ratified, proceed accordingly. **Mitigation:** Either (a) require user-authored ratification files to live in a path no agent can write to (settings.json `permissions.deny`), or (b) require ratification to come from a tool the agent cannot invoke (Pushover ack callback, signed git commit, etc.). **BUG-6 โ€” `bypassPermissions` + role-boundary enforced only by text instructions.** PM-tier agents use `permissionMode: bypassPermissions` to avoid permission prompts on routine work. The agent MD has a \"HARD ROLE BOUNDARY โ€” FORBIDDEN actions\" section listing paths the agent must not write to. Enforcement is text-instruction only. Permission system is binary at the tool level (allow/deny entire tool); path-level constraints inside an allowed tool are policy, not enforcement. Agent in degraded state (post-compact, confused) could violate role boundary. **Mitigation:** PreToolUse hook on `Edit`/`Write` for the agent reads target path and rejects if it matches FORBIDDEN paths. Or: granular `permissions.allow` / `permissions.deny` rules in settings.json with path globs. **BUG-7 โ€” Documentation drift across multiple \"source of truth\" docs.** Project has 5+ documents claiming to be canonical (CLAUDE.md global instructions, multiple plan files, multiple memory files, agent MDs that duplicate rules). Operator updates one, others drift. Agents read different versions and produce inconsistent behavior. **Mitigation:** One canonical doc per topic; other docs include only a one-line summary + pointer. Add a FileChanged hook that, when the canonical doc changes, writes a \"review needed\" notification. **BUG-8 โ€” Tools envelope drift.** Agent MDs declare `tools:` and `disallowedTools:` arrays. Both drift over time. Real example: PM agent had `WebFetch` and `WebSearch` disallowed; later needed to read public Claude Code changelog โ†’ had to spawn an extra sub-agent just for that. `TaskStop` was disallowed โ†’ couldn't kill stuck sub-agent tasks. **Mitigation:** Quarterly \"tools envelope audit\" per agent. Cross-reference declared tools vs actually-invoked tools across N sessions of logs. **BUG-9 โ€” Agent MD bloat.** Production agent MDs have grown to 800-900 lines. Loaded into context on every wake. Inflates context bloat, slows wake, harder to maintain. **Mitigation:** Convention: \"core spec โ‰ค200 lines, must-read on every wake. Appendix sections marked `[OPTIONAL โ€” read only on relevant directive]`.\" Explicit size budget per agent tier. **BUG-10 โ€” Sub-agent integrity inheritance.** Parent agent dispatches sub-agent via `Agent` tool. Sub-agent inherits parent's session context. There is no validation that the sub-agent's frontmatter (model, tools, permissionMode) is appropriate for the dispatched task. Trust model assumes the parent vets the sub-agent before dispatch; in practice, parents grab the closest-named sub-agent without auditing its frontmatter. **Mitigation:** Pre-dispatch hook surfaces sub-agent's frontmatter to parent and requires explicit acknowledgment. Or: agent registry with declared scopes the parent must match. **BUG-11 โ€” `CLAUDE.md` size drift.** Project-level `CLAUDE.md` (always-loaded) has grown to >40KB. CLI surfaces a size warning. Loading on every conversation start adds latency + context cost. Same root as BUG-9 โ€” \"add another landmine warning\" is easy, consolidation is hard. **Mitigation:** Move detailed history sections to dated archives (`docs/CLAUDE_MD_HISTORY_PRE_.md`), keep CLAUDE.md to current-state critical rules + pointers. **BUG-12 โ€” Background agent task explosion (`TaskCreate` no rate limit / dedup).** Long-running coordinator agent uses `TaskCreate` to track work. With many simultaneous sub-agent dispatches, task list grows to 30+ entries. No deduplication check, no soft cap warning. **Mitigation:** TaskCreated hook (CC 2.1.108+) logs every task creation, warns at >30/session, near-duplicate detection (Levenshtein <0.3 against existing task descriptions). --- ### CROSS-CUTTING THEMES 1. **Integrity surfaces measure shape, not substance.** Audit logs, ratification files, heavy-script gates all check that an artifact exists with the right shape. BUGS 2, 4, 5 all let agents satisfy the shape without satisfying the underlying intent. Pattern fix: bind the artifact to runtime context (agent identity, content signature) so the surface measures what we actually want. 2. **No mechanism to enforce \"this rule lives in one place.\"** BUGS 7, 9, 11 are all the same: same content duplicated across files, edits drift, agents read inconsistent versions. Pattern fix: single canonical source per topic + FileChanged hook. 3. **No structural compaction-survival pattern.** BUG 1 is the worst symptom; BUGS 8, 9, 10 share the same shape โ€” agent state degrades across sessions/compactions because no machine-readable surface persists the relevant context. Pattern fix: PreCompact hook + session-state file + wake-time prefix that reads it. 4. **Hook design needs first-class enforcement primitives.** BUGS 3, 4, 6 all stem from hooks being \"scripts the system runs at events\" without the system providing timeouts, depth tracking, or content-based detection. Pattern fix: hook-runtime primitives (timeout, depth-counter, content-hash) so hook authors don't have to build them per-script. --- ### SUGGESTED UPSTREAM CONSIDERATIONS Not bug reports against Claude Code โ€” feature considerations that would mitigate the patterns above: - Native PreCompact hook with structured payload (agent gets a serialized \"session-state since last compact\" object on the post-compact wake) - Runtime agent identity in hook context (`$CLAUDE_SUBAGENT_TYPE` and `$CLAUDE_PARENT_AGENT` reliably surfaced so impersonation can be detected at the hook layer) - Hook timeout + depth as runtime primitives (default 30s timeout + max depth 3 enforced by the runtime; hook authors opt into longer) - Path-level permission rules in settings.json (`permissions.deny: [\"Edit(src/**)\"]` enforced regardless of `bypassPermissions`) - Sub-agent dispatch warning when parent dispatches sub-agent with elevated tools - Agent MD size budget (soft warning when an agent MD exceeds N lines or KB) - `TaskCreate` rate-limit + dedup (surface duplicate task descriptions; warn at session count >30) --- ### SUMMARY The cluster pattern this FR has been documenting points at the same architectural class: **the runtime's failure modes are mostly observability / durability / normalization / mechanical-enforcement gaps, and agent-behavior failure modes layer on top of them.** Point fixes treat individual symptoms; the cluster IS the bug. This 12-bug catalog is the operator's attempt to surface the architectural-class abstraction so it can be addressed at the runtime layer rather than (re-)solved by every project running long-lived multi-agent workflows.", "url": "https://github.com/anthropics/claude-code/issues/54393", "createdAt": "2026-04-28T17:04:13Z", "updatedAt": "2026-08-13T00:41:46Z", "timestamp": "2026-08-13T00:41:46Z", "metrics": { "reactions": 0, "comments": 27 }, "labels": [ "enhancement", "area:hooks", "area:agents", "area:permissions" ], "author": "ThatDragonOverThere", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:54426", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] v2.1.121: Opus 4.7 (1M context) max-effort window silently self-downgrades to Sonnet 4.6 mid-session AND /compact does not fire at context limit", "text": "# [Bug] v2.1.121: Opus 4.7 (1M context) max-effort window silently self-downgrades to Sonnet 4.6 mid-session AND `/compact` does not fire at context limit **Version:** Claude Code 2.1.121 (Node.js path, Windows) **Severity:** Critical โ€” compound failure: model-tier integrity broken + the runtime's own documented context-limit recovery primitive (`/compact`) does not execute. Operator's only recovery path is manual `/model` re-select + `please continue`, which is opaque to any agent reading session metadata for tier verification. --- ## Repro 1. Start a Claude Code window with explicit `/model opus[1m]` + max effort (or set as default). 2. Run long-form work that approaches the context limit (~250K tokens on 1M-context Opus). 3. At the context wall, observe Claude Code's prompt: ``` Context limit reached ยท /compact or /clear to continue ยท /model sonnet[1m] ``` 4. Run `/model` to query the active model. 5. Observe: model has silently downgraded to **Sonnet 4.6** without any operator action and without any prior banner/log entry. 6. Run `/compact`. Observe: command does not execute / does not produce a compaction. 7. Recovery: `/model opus[1m]` (default) with max effort, then `please continue`. --- ## Two distinct failure modes compounding ### 1. Silent model self-downgrade Opus 4.7 1M max-effort โ†’ Sonnet 4.6 The operator-selected tier is not preserved across the session. No log entry, no banner, no in-session acknowledgment that the model has changed. The agent ran on Sonnet for an unknown portion of the session while the operator believed the agent was running on Opus. This is the **second** documented self-downgrade observation in 24 hours. First instance: Apr 27 evening, a long-running agent self-downgraded Opus Max โ†’ Sonnet at some point during the daytime session before being manually switched back to Opus Max for overnight work. (That instance was not filed standalone at the time because Sonnet behavior happened to be the better outcome on that task โ€” but the downgrade itself is a tier-integrity bug regardless of which direction the quality cuts.) This second instance โ€” fresh deliberate 1M max-effort selection in a brand-new window, downgrades anyway, discovered only via `/model` query at the context wall โ€” is a clear regression worth filing. ### 2. `/compact` non-execution at context limit The slash command listed in the context-limit message *itself* (`Context limit reached ยท /compact or /clear to continue`) did not produce a compaction when invoked. The runtime's published recovery path for its own published context-limit message is broken in v2.1.121. The only path back into the session was: 1. `/model opus[1m]` (manual re-selection of the operator-intended tier) 2. `please continue` (manual continuation prompt) --- ## Why this matters in autonomous / overnight workflows The two failure modes compose. An operator who sets Opus before bed for autonomous overnight work could wake up to find: - a Sonnet-tier agent has been running for most of the night - the agent is stranded at the context wall - there is no automatic recovery โ€” `/compact` won't fire - the only revival path is manual `/model` re-select, which an autonomous agent cannot perform on its own session This is the single-window analogue of the sub-agent integrity inheritance bug ([#54393 BUG-10](https://github.com/anthropics/claude-code/issues/54393)) โ€” operator selects a tier, runtime silently degrades it, no validation surface catches the drift. --- ## Hypothesis (not validated, needs Anthropic-side trace) The `/compact` failure may be tier-gated and may misfire when the actual-running-tier does not match the operator-selected-tier. The two failure modes may share a single root cause in v2.1.121's model-tier persistence path. Worth checking whether the `/compact` execution path has any code that conditions on `currentModel` vs `userSelectedModel` or equivalent. --- ## Ask - Stop silent model downgrades. If the runtime needs to change tier mid-session for capacity / load / billing reasons, surface a banner or log entry at the moment of the change so the operator can detect it before walking off a context wall on the wrong tier. - Fix `/compact` execution at the context limit so the runtime's own published recovery path actually works. - Surface the active-tier mismatch in `/usage`, the statusline, or the context-limit message itself so operators can detect the downgrade before it costs a multi-hour session. --- *Cross-references: [#54393](https://github.com/anthropics/claude-code/issues/54393) (12-bug coordination catalog including BUG-10 sub-agent integrity inheritance), [#53610](https://github.com/anthropics/claude-code/issues/53610) (architectural gaps for unattended overnight operation including per-session-throttle observability).*", "url": "https://github.com/anthropics/claude-code/issues/54426", "createdAt": "2026-04-28T19:07:24Z", "updatedAt": "2026-08-13T14:29:27Z", "timestamp": "2026-08-13T14:29:27Z", "metrics": { "reactions": 0, "comments": 8 }, "labels": [ "bug", "platform:windows", "area:model", "stale" ], "author": "ThatDragonOverThere", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:54583", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] \\u in Windows path is interpreted as Unicode escape sequence, corrupting file paths for usernames starting with u followed by hex digits", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? #### Description On Windows, when a username contains a sequence that looks like a Unicode escape (e.g. uabcdef), Claude Code corrupts the path in all file-related tool calls (Read, Write, Edit, Bash, Glob, Grep). The backslash-u combination in C:\\Users\\uabcdef is silently interpreted as a Unicode escape sequence, producing a corrupted character in place of \\ua โ€” a path that does not exist. #### Workaround Building the path via a PowerShell intermediate variable avoids the issue: $u = \"uabcdef\" $dest = \"C:\\Users\\$u\\path\\to\\file.txt\" [System.IO.File]::WriteAllText($dest, $content, [System.Text.Encoding]::UTF8) POSIX-style paths in Bash (/c/Users/uabcdef/...) also work, but break when the file content contains single quotes (heredoc parsing issue). #### Impact Any Windows user whose username matches the pattern u[0-9a-fA-F]{4,} (common in corporate environments where usernames are employee IDs) is affected. All file tool calls silently target a non-existent path. ### What Should Happen? #### Expected behavior The path C:\\Users\\uabcdef\\file.txt should be passed as-is to the OS without any Unicode escape interpretation. #### Actual behavior C:\\Users\\uabcdef\\file.txt is silently rewritten to a path containing a spurious Unicode character (e.g. U+0300 range), causing all file operations to fail with EPERM or File not found. ### Steps to Reproduce 1. Run Claude Code on Windows with a username that starts with u followed by 4โ€“6 hexadecimal digits (e.g. uabcdef, u1a2b3c). 2. Ask Claude to read, write, or edit any file under the user home directory. 3. Observe that the tool call uses a corrupted path such as C:\\Users[corrupted]bcdef\\... instead of C:\\Users\\uabcdef\\.... ### Claude Model Sonnet (default) ### Is this a regression? Yes, this worked in a previous version ### Last Working Version na ### Claude Code Version 2.1.121 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell Other ### Additional Information #### Environment - OS: Windows 11 Enterprise 10.0.22631 - Shell: Bash (Git Bash / MSYS2) โ€” PowerShell also available - Claude Code version: latest CLI - Username pattern affected: any username matching u[0-9a-fA-F]{4,} (e.g. uabcdef)", "url": "https://github.com/anthropics/claude-code/issues/54583", "createdAt": "2026-04-29T08:04:37Z", "updatedAt": "2026-08-13T14:31:23Z", "timestamp": "2026-08-13T14:31:23Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "bug", "has repro", "platform:windows", "area:tools", "stale" ], "author": "mcarbonneaux", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:54750", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Bug: Claude Code current session limit reaches 100% despite low visible local session usage", "text": "# Bug: Claude Code shows current session limit exhausted despite very low visible local session usage ## Summary Claude Code / Claude Desktop reported the **current session limit as 100% used** and blocked further Claude Code usage, even though the usage visible locally in Claude Code and local transcripts did not appear to justify exhausting a Max 20x current-session limit. This could be either: 1. A **usage accounting / attribution bug**, where the current session limit is being computed incorrectly or includes usage not represented in local Claude Code usage views. 2. A **security / token attribution issue**, where usage from another device/session/token is being charged to the same Claude Code account but is not visible in local Claude Code transcripts. At minimum, Claude Code's `/usage` UI appears insufficient for diagnosing why the current session was exhausted. ## Environment - Claude Code version: `2.1.123` - OS: macOS `26.2` (`arm64`) - Node.js: `v22.17.0` - npm: `10.9.2` - Plan shown in Claude UI: Max 20x - Timezone: Europe/Madrid - Date observed: 2026-04-29 ## What happened At approximately `2026-04-29 18:25 CEST`, Claude Desktop and Claude Code showed: - Current session: `100% used` - Reset: around `21:40 Europe/Madrid` - Current week, all models: `60% used` - Current week, Sonnet only: `1% used` In Claude Code `/usage`, the visible local session summary was small: ```text Session Total cost: $0.76 Total duration (API): 53s Total duration (wall): 2h 53m 5s Total code changes: 0 lines added, 0 lines removed Usage by model: claude-haiku-4-5: 370 input, 14 output, 0 cache read, 0 cache write claude-opus-4-7: 21 input, 2.5k output, 436.2k cache read, 76.9k cache write Current session: 100% used Resets 9:40pm (Europe/Madrid) Current week (all models): 60% used Current week (Sonnet only): 1% used ``` The same local Claude Code transcript recorded the hard limit after a trivial prompt: ```text timestamp=2026-04-29T16:26:16.363Z user prompt=\"a\" timestamp=2026-04-29T16:26:16.859Z message=\"You've hit your limit ยท resets 9:40pm (Europe/Madrid)\" ``` This makes the limit feel disconnected from the visible local Claude Code usage. ## Local transcript usage cross-check I also inspected local Claude Code transcript usage using `ccusage`: ```bash npx ccusage@latest blocks --json ``` Relevant blocks for the same day: ```text 2026-04-29T04:00:00Z - 2026-04-29T09:00:00Z totalTokens=363,679,444 cacheReadInputTokens=358,827,700 cacheCreationInputTokens=4,361,929 outputTokens=478,605 models=claude-opus-4-7, claude-haiku-4-5, claude-sonnet-4-6 2026-04-29T09:00:00Z - 2026-04-29T14:00:00Z totalTokens=214,817,570 cacheReadInputTokens=211,368,028 cacheCreationInputTokens=3,297,689 outputTokens=151,103 models=claude-opus-4-7, claude-opus-4-6 2026-04-29T14:00:00Z - 2026-04-29T19:00:00Z isActive=true totalTokens=35,577,623 cacheReadInputTokens=34,247,311 cacheCreationInputTokens=1,269,568 outputTokens=60,358 models=claude-opus-4-7, claude-haiku-4-5 ``` The active block corresponds to approximately `16:00-21:00 CEST`. At the time Claude Code reported the current session as exhausted, local transcript usage for the active block was only about `35.6M` tokens according to `ccusage`. I understand `ccusage` is not an official Anthropic source of truth, but the discrepancy is large enough that the CLI should expose enough attribution/debug information to explain it. ## Expected behavior One of the following should happen: - If current-session usage is exhausted, Claude Code `/usage` should show which surfaces/sessions/tokens/models contributed enough usage to exhaust it. - If usage from Claude Desktop, claude.ai, Claude in Chrome, other devices, or other Claude Code tokens is included, `/usage` should make that explicit and provide a breakdown or at least a clear attribution category. - If the session total shown by Claude Code is not the same accounting scope as \"Current session 100% used\", the UI should label those scopes clearly. - A trivial prompt after a low visible local session total should not immediately hit the limit unless other usage is clearly attributed. ## Actual behavior Claude Code showed: - A very small visible local session summary (`$0.76`, ~436k cache read in the visible session summary). - At the same time, `Current session: 100% used`. - The next trivial prompt immediately produced a hard limit error. - Local transcript usage for the active block did not explain the current-session exhaustion. ## Why this matters From the user's perspective, there is no way to tell whether: - the current-session usage calculation is wrong, - usage from another Claude surface is being included, - a stale/old Claude Code process is consuming usage, - another Claude Code authorization token is consuming usage, or - the account/session has been compromised. This makes it difficult to distinguish a product bug from a security incident. ## Related issues found I searched existing `anthropics/claude-code` issues and found several likely related reports: - https://github.com/anthropics/claude-code/issues/38335 โ€” Max plan 5-hour session limit exhausted abnormally fast since March 23, 2026; users report 21% to 100% jumps on a single prompt. - https://github.com/anthropics/claude-code/issues/37394 โ€” Max plan hitting limits extremely fast; user reports one message plus two Python script calls jumping usage from 0% to 24%. - https://github.com/anthropics/claude-code/issues/42052 โ€” Max 20x plan reaches 100% after ~2 hours of light work; explicitly links several related abnormal usage drain reports. - https://github.com/anthropics/claude-code/issues/41788 โ€” Max 20 plan exhausted within ~70 minutes after reset; suspected server-side cached/thinking-token accounting or prompt-cache invalidation. - https://github.com/anthropics/claude-code/issues/41930 โ€” broader report on abnormal usage limit drain across paid tiers, including possible prompt-caching and session-resume causes. This issue may overlap with those, but the specific additional concern here is the **diagnostic mismatch**: Claude Code's local `/usage` and transcript-derived usage do not explain why the global current-session limit is exhausted. The product should expose enough attribution to determine whether usage came from this local Claude Code session, another Claude surface, another token/device, or a server-side accounting bug. ## Suggested improvements Please consider adding one or more of: - A server-side usage attribution breakdown in `/usage`, grouped by product surface: Claude Code, Claude Desktop, claude.ai, Claude in Chrome, etc. - A breakdown by active Claude Code token/session/device where possible. - A clearer distinction between \"this local Claude Code session\" and \"global current 5-hour account/session limit\". - A warning when usage contributing to the current session is coming from outside the local machine/transcript. - A support/debug export command that produces a sanitized usage report users can attach to Anthropic support. ## Attachments available I can attach a screenshot of Claude Code `/usage` showing: - Local session total cost: `$0.76` - Current session: `100% used` - Reset: `9:40pm Europe/Madrid` - Current week all models: `60% used` - Current week Sonnet only: `1% used` I can also provide a private support report with account/session screenshots and sanitized local transcript excerpts. I am intentionally not including account IDs, authorization tokens, bearer tokens, or private project names in this public issue.", "url": "https://github.com/anthropics/claude-code/issues/54750", "createdAt": "2026-04-29T17:03:11Z", "updatedAt": "2026-08-13T07:38:46Z", "timestamp": "2026-08-13T07:38:46Z", "metrics": { "reactions": 11, "comments": 17 }, "labels": [ "bug", "platform:macos", "area:cost" ], "author": "Troskiev83", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:55008", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "/reload-plugins does not reload hook scripts โ€” stale hooks persist until session restart", "text": "## Bug `/reload-plugins` does not reload plugin hook scripts into the running session. After updating a plugin that changes a hook, the old hook code continues to execute until the Claude Code process is killed and restarted. ## Steps to reproduce 1. Install a plugin with a `PreToolUse` hook (e.g., one that denies certain shell commands). 2. Publish a new plugin version that changes the hook logic (e.g., removes an entry from a deny list). 3. Run `/plugin marketplace update ` โ€” succeeds, new version appears on disk. 4. Run `/reload-plugins` โ€” reports success with a count of loaded items. 5. Trigger the hook โ€” **old behavior persists.** The denied command is still denied despite the fix being on disk. ## Evidence Plugin version 1.4.11 had `uv` in a HOST_TOOLS deny list. Version 1.4.12 removed it. After update + reload: - `/Users/.../.claude/plugins/cache/.../1.4.12/hooks/scripts/lib/host-container-tools.sh` โ€” correct (no `uv`) - Running session still blocks `uv` with the 1.4.11 error message The only workaround is to kill and restart the Claude Code session. ## Impact Hooks are the primary mechanism for enforcing agent behavior constraints (blocking dangerous commands, enforcing workflow rules, etc.). When a hook has a bug that incorrectly blocks valid commands, the inability to hot-reload the fix means: - Every running session must be killed and restarted - There is no way to verify which hook version is loaded without filesystem inspection - `/reload-plugins` gives false confidence โ€” it reports success but hooks remain stale ## Expected behavior `/reload-plugins` should reload ALL plugin components: skills, hooks, settings, and any other plugin-provided artifacts. If it cannot reload certain components, it should clearly state what was and was not reloaded. ## Environment - Claude Code CLI (macOS, Darwin 25.3.0) - Claude Opus 4.6", "url": "https://github.com/anthropics/claude-code/issues/55008", "createdAt": "2026-04-30T13:31:54Z", "updatedAt": "2026-08-13T14:35:25Z", "timestamp": "2026-08-13T14:35:25Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "bug", "platform:macos", "area:hooks", "area:plugins", "stale" ], "author": "wphillipmoore", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55381", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Cowork ElevenLabs plugin: ${user_config.output_dir} never substituted โ€” all TTS/music generation fails with ENOENT", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When using the ElevenLabs plugin in Cowork (not Claude Code CLI), all audio generation tools โ€” generate_tts, generate_music, generate_sound_effect โ€” fail immediately with: ``` Failed to generate speech: ENOENT: no such file or directory, mkdir '${user_config.output_dir}' ``` The plugin's output directory config accepts a path during setup, but the `${user_config.output_dir}` template string is passed literally to `mkdir` rather than being resolved to the configured path. This happens on fresh install AND after reinstall with an explicit path set. Account tier: ElevenLabs Starter (paid). API key is valid โ€” the error occurs before any API call is made, purely in the plugin's file system setup. ### What Should Happen? The output directory path configured during plugin setup should be substituted into ${user_config.output_dir} so the plugin can create the directory and save generated audio files. generate_tts, generate_music, and generate_sound_effect should all return audio files saved to the configured path. ### Error Messages/Logs ```shell Failed to generate speech: ENOENT: no such file or directory, mkdir '${user_config.output_dir}' Same error for all three tools: - generate_tts - generate_music (also fails with missing music_generation permission on free tier, but output_dir error blocks even on paid Starter tier) - generate_sound_effect Error occurs on every call regardless of text content or voice selection. Reproduced across: - Fresh install of ElevenLabs plugin - Uninstall + reinstall with explicit output path configured - ElevenLabs Starter tier (paid) with valid API key ``` ### Steps to Reproduce 1. Install the ElevenLabs plugin in Cowork via the plugin marketplace 2. Configure with a valid ElevenLabs API key and set an output directory path (e.g. /Users/username/Downloads) 3. In a Cowork conversation, ask Claude to generate speech: \"Generate TTS saying hello world\" 4. Plugin calls generate_tts 5. Immediately fails with: ENOENT: no such file or directory, mkdir '${user_config.output_dir}' Alternate reproduction: 1. Uninstall the plugin completely 2. Reinstall fresh with API key and explicit output path 3. Same error persists โ€” the configured path is never substituted for ${user_config.output_dir} ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Cowork desktop app (not Claude Code CLI) - macOS ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information This bug is in the Cowork desktop app plugin, not Claude Code CLI. The ElevenLabs plugin is installed via the Cowork plugin marketplace. Note: The underlying ElevenLabs MCP server (elevenlabs/elevenlabs-mcp) had a related path-handling bug (Issue #71) that was fixed in PR #82 on 2025-10-01. However, the Cowork plugin wrapper layer is failing before the MCP server is even reached โ€” the ${user_config.output_dir} template variable substitution happens in the Cowork plugin layer itself. This makes the ElevenLabs plugin completely non-functional in Cowork. All three generation tools (TTS, music, sound effects) are blocked. Given that ElevenLabs is a featured connector in Cowork and this workflow (AI voice + music for video content) is a primary use case, this is a high-priority regression.", "url": "https://github.com/anthropics/claude-code/issues/55381", "createdAt": "2026-05-01T17:03:50Z", "updatedAt": "2026-08-13T14:32:04Z", "timestamp": "2026-08-13T14:32:04Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "platform:macos", "area:cowork", "area:plugins", "stale" ], "author": "SoWrongImRight", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55387", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Worktree background full checkout fails with 'not-a-git-repo' when repo has `submodule.recurse = true`", "text": "## Summary When creating a Claude Code worktree against a repo that has `submodule.recurse = true` set in its local git config, the staged background full checkout always fails with `Background full checkout failed: not-a-git-repo`. The worktree directory ends up partially populated (only the selective paths โ€” `CLAUDE.md`, `.claude`, `.mcp.json` โ€” are checked out) and the new conversation cannot be entered. I reproduced this against the Claude desktop app and tracked it down to the `stageCheckout` implementation in the bundled JS. ## Environment - Claude desktop app: 1.5354.0 - Claude Code CLI: 2.1.126 - macOS: 26.3.1 - git: 2.50.1 (Apple Git-155) - Repo has 2 git submodules and `submodule.recurse = true` in `.git/config` ## Repro 1. Clone any repo that has at least one submodule. 2. In its local config, set `git config submodule.recurse true` (a perfectly valid workflow setting โ€” it just makes pulls/checkouts recurse). 3. Open the repo in the Claude desktop app and start a new conversation with the worktree toggle enabled. 4. The background pre-creation surfaces a red banner: `Something went wrong โ€ฆ Background full checkout failed: not-a-git-repo`. ## Expected Worktree creation succeeds. Submodules in the new worktree don't have to be initialized โ€” the staged checkout simply shouldn't try to recurse into them. ## Actual The promise returned by `stageCheckout` rejects. Running the same command Claude Code runs, by hand, in the freshly-created worktree: ``` $ git -c core.longpaths=true checkout HEAD -- . ':(exclude).claude' fatal: not a git repository: ../../../../../.git/worktrees//modules/packages/ fatal: could not reset submodule index ``` That stderr matches the `not a git repository` branch in the error classifier, which is then surfaced as `not-a-git-repo` in the banner. Adding `-c submodule.recurse=false` to the same command makes it succeed (exit 0): ``` $ git -c submodule.recurse=false -c core.longpaths=true checkout HEAD -- . ':(exclude).claude' $ echo $? 0 ``` ## Root cause In the bundled `app.asar/.vite/build/index.js`, `stageCheckout` invokes: ```js this.execGit( [...t, \"-c\", \"core.longpaths=true\", \"checkout\", \"HEAD\", \"--\", \".\", \":(exclude).claude\"], A, { extraEnv: { LC_ALL: \"C\" } } ) ``` `t` is just the LFS filter overrides; nothing is passed to suppress submodule recursion. With `submodule.recurse = true` in the parent repo's config, this `git checkout` recurses into submodules โ€” but in a brand-new worktree the submodules' gitlinks (`.git/worktrees//modules/`) have never been created, so git aborts with `not a git repository`. The same call site likely needs the fix in both the selective and full-checkout invocations. ## Suggested fix Pass `-c submodule.recurse=false` (or equivalently `--no-recurse-submodules` where the subcommand supports it) to the staged checkout commands in `stageCheckout`. Worktrees never have initialized submodules at staging time, so recursion is never useful here โ€” only harmful. A minimal patch would be inserting `\"-c\", \"submodule.recurse=false\"` into the args array right alongside the existing `-c core.longpaths=true`. Same treatment is probably warranted for the selective checkout a few lines above. ## Workaround For anyone hitting this: move `submodule.recurse = true` out of shared `.git/config` and into the main worktree's per-worktree config: ``` git config --unset submodule.recurse git config --worktree submodule.recurse true # extensions.worktreeConfig must be true ``` Then new worktrees won't inherit the setting and Claude Code's staged checkout will succeed, while the main worktree continues to recurse on pulls/checkouts as before.", "url": "https://github.com/anthropics/claude-code/issues/55387", "createdAt": "2026-05-01T17:14:41Z", "updatedAt": "2026-08-13T14:30:47Z", "timestamp": "2026-08-13T14:30:47Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "duplicate" ], "author": "thomasqbrady", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55447", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Context leakage between sessions or invalid context persistence", "text": "**Bug Description** Session included incorrect context and claimed I provided it - no idea where it came from (probably from another session with invalid info) **Environment Info** - Platform: darwin - Terminal: WarpTerminal - Version: 2.1.126 - Feedback ID: 67cfb3a6-45c3-4bdc-b4d0-24cb474a918c **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for /Users/michaelprescott/.local/share/claude/versions/2.1.126 (expected in multi-process scenarios)\\n at r86 (/$bunfs/root/src/entrypoints/cli.js:2768:2177)\\n at HD8 (/$bunfs/root/src/entrypoints/cli.js:2768:1257)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-01T21:32:41.369Z\"},{\"error\":\"Error: ENOENT: no such file or directory, open '/var/folders/g3/n8nqgf6541n0h352qjtww6c00000gn/T/TemporaryItems/NSIRD_screencaptureui_7WwRLt/Screenshot 2026-05-01 at \\r 2.34.12 PM.png'\\n at readFileSync (unknown)\\n at readFileBytesSync (/$bunfs/root/src/entrypoints/cli.js:55:1079)\\n at mZ9 (/$bunfs/root/src/entrypoints/cli.js:587:14964)\\n at (/$bunfs/root/src/entrypoints/cli.js:642:170)\\n at map (native:1:11)\\n at M (/$bunfs/root/src/entrypoints/cli.js:642:161)\\n at f (/$bunfs/root/src/entrypoints/cli.js:643:154)\\n at tM1 (/$bunfs/root/src/entrypoints/cli.js:511:1976)\\n at dispatch (/$bunfs/root/src/entrypoints/cli.js:511:2652)\\n at (/$bunfs/root/src/entrypoints/cli.js:497:111856)\",\"timestamp\":\"2026-05-01T21:42:01.852Z\"},{\"error\":\"Error: ENOENT: no such file or directory, open '/var/folders/g3/n8nqgf6541n0h352qjtww6c00000gn/T/TemporaryItems/NSIRD_screencaptureui_7WwRLt/Screenshot 2026-05-01 at \\r 2.34.12 PM.png'\\n at readFileSync (unknown)\\n at readFileBytesSync (/$bunfs/root/src/entrypoints/cli.js:55:1079)\\n at mZ9 (/$bunfs/root/src/entrypoints/cli.js:587:14964)\\n at (/$bunfs/root/src/entrypoints/cli.js:642:170)\\n at map (native:1:11)\\n at M (/$bunfs/root/src/entrypoints/cli.js:642:161)\\n at f (/$bunfs/root/src/entrypoints/cli.js:643:154)\\n at tM1 (/$bunfs/root/src/entrypoints/cli.js:511:1976)\\n at dispatch (/$bunfs/root/src/entrypoints/cli.js:511:2652)\\n at (/$bunfs/root/src/entrypoints/cli.js:497:111856)\",\"timestamp\":\"2026-05-01T21:42:11.113Z\"},{\"error\":\"Error: ensureToolResultPairing: repaired missing tool_result blocks (49 -> 49 messages). Message structure: [0] user; [1] assistant(id=msg_011e1mq7g5teTG5f1Fqut9yP, tool_uses=[toolu_0158q4cHK2rHvDW4osV9JfJf]); [2] user(tool_results=[toolu_0158q4cHK2rHvDW4osV9JfJf]); [3] assistant(id=msg_01BRvBKRsNETSgrF9ikzaKwg, tool_uses=[toolu_01EhoN33Qhpje5Y4dUm2ofc3,toolu_01AhsaRmjMwYH6k5d6rb59sm,toolu_01LgatYGxDzTmH6otzxnNEB5]); [4] user(tool_results=[toolu_01EhoN33Qhpje5Y4dUm2ofc3,toolu_01AhsaRmjMwYH6k5d6rb59sm,toolu_01LgatYGxDzTmH6otzxnNEB5]); [5] assistant(id=msg_014T7f5Xqiwp1BPwPyb9bvmf, tool_uses=[toolu_01RFYxK9yTa4gVFhJxFP5hDx,toolu_01JhUyTZgony64wo1ByaDS6q,toolu_01QHL1xmEQ5diDQrkZyX71Hw,toolu_01G1QCk6sc4TraAnTPjmU2Wn,toolu_01NvEWuzTDiZqx8BdQjkt3rN,toolu_01AcwctLEqPVcxLVxwikUPmS,toolu_01T2F953tq51FfmKBcabGsS9,toolu_01H4ooy9ewLQShpzWf6bKGhc,toolu_01AdTH33EbpvDFtitwFZyBsZ]); [6] user(tool_results=[toolu_01RFYxK9yTa4gVFhJxFP5hDx,toolu_01JhUyTZgony64wo1ByaDS6q,toolu_01QHL1xmEQ5diDQrkZyX71Hw,toolu_01G1QCk6sc4TraAnTPjmU2Wn,toolu_01NvEWuzTDiZqx8BdQjkt3rN,toolu_01AcwctLEqPVcxLVxwikUPmS,toolu_01T2F953tq51FfmKBcabGsS9,toolu_01H4ooy9ewLQShpzWf6bKGhc,toolu_01AdTH33EbpvDFtitwFZyBsZ]); [7] assistant(id=msg_01S7Mz6SxLw3dKT3jHv2mNtW, tool_uses=[toolu_01RZFFLhDa3JdhU2pQkK4Gsi,toolu_01ARqovtrLLWnfqcpziTU3FT,toolu_01UabumGeAu3FyKu9ab1UNg2,toolu_011ns58qSc32sTGQZN2mZYTF]); [8] user(tool_results=[toolu_01UabumGeAu3FyKu9ab1UNg2,toolu_011ns58qSc32sTGQZN2mZYTF,toolu_01RZFFLhDa3JdhU2pQkK4Gsi,toolu_01ARqovtrLLWnfqcpziTU3FT]); [9] assistant(id=msg_01QCh5YZfbBhkqL3XfNtBExu, tool_uses=[toolu_014va2uUskTMSLMo8Sk3T8Bj,toolu_01JAyuVvUZH7TBqMu2poauJ2,toolu_01VRnMQzvHG2fb3hu2AyjhrJ,toolu_0136PXFPuEz2ZA2F6bsr44dW]); [10] user(tool_results=[toolu_014va2uUskTMSLMo8Sk3T8Bj,toolu_01JAyuVvUZH7TBqMu2poauJ2,toolu_01VRnMQzvHG2fb3hu2AyjhrJ,toolu_0136PXFPuEz2ZA2F6bsr44dW]); [11] assistant(id=msg_01LZUj7V8bmVF8QCYBipZF28, tool_uses=[toolu_01NvT8kugRZjfq8Mvucjd6aa,toolu_01FMrBT1TXWvktQRVxM4oKPr,toolu_01PnrkfXCZ9D8FshUca1gL7r]); [12] user(tool_results=[toolu_01NvT8kugRZjfq8Mvucjd6aa,toolu_01FMrBT1TXWvktQRVxM4oKPr,toolu_01PnrkfXCZ9D8FshUca1gL7r]); [13] assistant(id=msg_01YJ6DAGuRo2bdf4qniQiigN, tool_uses=[toolu_01EFFvg8LtCR86hNwvG9BwLh,toolu_011mqosuKZELoHSQyeBNjmmy]); [14] user(tool_results=[toolu_01EFFvg8LtCR86hNwvG9BwLh,toolu_011mqosuKZELoHSQyeBNjmmy]); [15] assistant(id=msg_01LNs7SS6Ly4AZ8q8zP3L381, tool_uses=[toolu_012Wm6fF9MxoDToupw7tgEcQ,toolu_018uQHhdY18uuZRAeqvdxWcU,toolu_019uVLfwjLSG32p99Mtt4rw3]); [16] user(tool_results=[toolu_012Wm6fF9MxoDToupw7tgEcQ,toolu_018uQHhdY18uuZRAeqvdxWcU,toolu_019uVLfwjLSG32p99Mtt4rw3]); [17] assistant(id=msg_01B69fksrssr1vYMs6h3Nbma, tool_uses=[toolu_01SbRJV7B12S8T9riNJUS2YA,toolu_01CtYi1ANxjkfkWvkJxXHx57,toolu_01XrttUU5w8fK5qmeBUjViET,toolu_01NTbytmpELQyC4oBf7JxDpA]); [18] user(tool_results=[toolu_01SbRJV7B12S8T9riNJUS2YA,toolu_01CtYi1ANxjkfkWvkJxXHx57,toolu_01XrttUU5w8fK5qmeBUjViET,toolu_01NTbytmpELQyC4oBf7JxDpA]); [19] assistant(id=msg_018CZu2txCAL5RT2aWU1CCHC, tool_uses=[toolu_01S8QEXXF8xLcFJ8Q7nPwVgT,toolu_015jWGbT5d84RQ2NnGAadXaF]); [20] user(tool_results=[toolu_01S8QEXXF8xLcFJ8Q7โ€ฆ ``` **Note:** Content was truncated.", "url": "https://github.com/anthropics/claude-code/issues/55447", "createdAt": "2026-05-01T21:57:55Z", "updatedAt": "2026-08-13T14:35:14Z", "timestamp": "2026-08-13T14:35:14Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "platform:macos", "area:core", "stale" ], "author": "mdprescott", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55453", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code extension webview tab restoration hangs Cursor IDE on workspace startup", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The Claude Code extension for Cursor (anthropic.claude-code) hangs Cursor's renderer process when Cursor attempts to restore previously open Claude Code editor tabs at workspace startup. The same extension, with the same session data, restores cleanly in VS Code โ€” this is a Cursor-specific interaction, but I'm filing here as well in case the extension can mitigate from its side or coordinate with Cursor on a fix. Cursor forum threads with detailed analysis: - https://forum.cursor.com/t/claude-code-tabs-cause-cursor-to-freeze-on-startup-stuck-loading/155722/18 - https://forum.cursor.com/t/extension-host-fails-to-initialize-timeout-waiting-for-auth-and-plugins-breaking-ai-agents-and-source-control/158539 Root cause (per Sanskar's analysis in the linked Cursor thread): the hang occurs in Cursor's registerWebviewPanelSerializer restore path for claudeVSCodePanel panels, before the extension's deserializeWebviewPanel handler executes. Even patching the handler to immediately dispose the panel doesn't prevent the hang. Workarounds: - In-session: close the Claude Code tabs while Cursor is hung; the extension host completes activation within seconds. - Preventive: close Claude Code tabs before quitting Cursor. - Heavy-handed: delete the workspace's state.vscdb or remove claudeVSCodePanel entries from memento/workbench.parts.editor. Possible mitigations on the extension side: - Defer or guard webview panel serializer registration so restoration never blocks the renderer. - Detect Cursor as the host and disable webview tab persistence until the upstream issue is fixed. Environment: - Cursor 3.2.16 (also reproduced on 3.0.12, 3.2.11) - macOS Apple Silicon, also reported on Windows - Claude Code extension 2.1.126 (and possibly earlier versions) This bug has had an active Cursor forum thread for over a month with multiple users affected. Filing here for cross-team visibility. ### What Should Happen? Cursor should open and load in Claude Code open chats in the open claude code extension tabs. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce - Open a project in Cursor with the Claude Code extension installed. - Open a Claude Code session as an editor tab (not the sidebar). - Quit Cursor with that tab still open. - Reopen the project. Cursor hangs on startup โ€” terminal, extensions, settings all become non-functional. Dev tools console shows extension host health-check failure, auth ready timeout, and No Connect transport provider registered cascades. ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version VSCode/Cursor extension (anthropic.claude-code): 2.1.126 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Other ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/55453", "createdAt": "2026-05-01T22:24:38Z", "updatedAt": "2026-08-13T14:30:41Z", "timestamp": "2026-08-13T14:30:41Z", "metrics": { "reactions": 4, "comments": 4 }, "labels": [ "bug", "platform:macos", "area:ide" ], "author": "DreamMachine144", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55562", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code Unusable on Windows (Max Subscription)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? I am writing as a paying Claude Max subscriber to formally report that Claude Code has been completely unusable on my Windows machine for an extended period, and to request either an immediate fix or a refund of my subscription. My Situation Subscription tier: Claude Max (paid) Operating system: Windows 11 Use case: Professional BIOS development workflows (CICD pipelines, multi-project codebase management) Total time spent troubleshooting today: Over 3 hours The Problem Both the Claude Code VS Code extension and the Claude Code CLI fail to initialize on my machine. Specifically: VS Code extension: Throws Subprocess initialization did not complete within 60000ms โ€” check authentication and network connectivity after every attempt to send a message. PowerShell CLI: claude --version works (returns 2.1.113), but claude enters interactive mode then silently exits, and claude --print \"hello\" hangs indefinitely with no response. This Is a Known Regression You Have Not Fixed This is not a configuration issue on my end. It is a regression in Claude Code starting from version 2.1.114 (released around April 18, 2026), affecting Windows users. Public GitHub issues confirming this: Issue #50559: [BUG] Subprocess initialization did not complete within 60000ms on Windows โ€” regression from 2.1.114 (opened April 18, 2026) Issue #50988: Claude Code extension times out on startup in VS Code (subprocess initialization) Issue #51732: VS Code extension 2.1.116 'Query closed before response received' on Windows 11 Issue #208 (claude-agent-sdk-python): ClaudeSDKClient hangs on Windows during initialization These issues have been open for over two weeks with no fix shipped. Multiple users have reported the same symptoms across versions 2.1.114 through 2.1.123, and the current 2.1.126 still has the same problem. What I Have Already Tried In good faith, I have spent significant time troubleshooting on my end before contacting you: Cleared %USERPROFILE%\\.claude cache and credentials Reinstalled Claude Code via npm โ€” npm install -g @anthropic-ai/claude-code Removed conflicting native installer at %USERPROFILE%\\.local\\bin\\claude.exe Downgraded both the CLI and VS Code extension to 2.1.113 Manually downloaded the .vsix file and installed it via code --install-extension Discovered the .vsix shipped without a Windows-compatible binary in resources/native-binary/, and manually copied a working claude.exe into the extension folder Disabled extension auto-update to prevent regression Replaced the binary with the freshly downloaded npm version Configured claudeCode.claudeProcessWrapper setting Tested stdio handshake manually โ€” confirmed the binary responds correctly to direct testing but fails when launched by the extension's stream-json protocol on Windows After all of this, the product still does not work. My Requests Given that I am paying for the Max tier and cannot use a flagship product feature for two weeks, I am requesting one of the following: An ETA for a Windows fix. If Anthropic is actively working on this, please provide a clear timeline. A confirmed workaround. If a workaround exists that is not yet publicly documented, please share it. A refund for the period during which Claude Code has been unusable on my Windows machine. I want to make clear that the issue is not with Anthropic's models or the web interface (claude.ai works fine on my Max subscription). The issue is specifically with Claude Code on Windows, which is a product I rely on for my work and which has been broken since I auto-updated. I would appreciate a substantive response, not a generic acknowledgment. If this is not resolved promptly, I will be canceling my subscription and seeking a refund through my payment provider. Thank you for your attention. Sincerely, [Your Name] [Your Email] [Your Anthropic Account Email, if different] Attachments / References: GitHub Issue #50559: https://github.com/anthropics/claude-code/issues/50559 GitHub Issue #50988: https://github.com/anthropics/claude-code/issues/50988 GitHub Issue #51732: https://github.com/anthropics/claude-code/issues/51732 GitHub Issue #208 (SDK): https://github.com/anthropics/claude-agent-sdk-python/issues/208 ### What Should Happen? I am writing as a paying Claude Max subscriber to formally report that Claude Code has been completely unusable on my Windows machine for an extended period, and to request either an immediate fix or a refund of my subscription. My Situation Subscription tier: Claude Max (paid) Operating system: Windows 11 Use case: Professional BIOS development workflows (CICD pipelines, multi-project codebase management) Total time spent troubleshooting today: Over 3 hours The Problem Both the Claude Code VS Code extension and the Claude Code CLI fail to initialize on my machine. Specifically: VS Code extension: Throws Subprocess initialization did not complete within 60000ms โ€” check authentication and network connectivity after every attempt to send a message. PowerShell CLI: claude --version works (returns 2.1.113), but claude enters interactive mode then silently exits, and claude --print \"hello\" hangs indefinitely with no response. This Is a Known Regression You Have Not Fixed This is not a configuration issue on my end. It is a regression in Claude Code starting from version 2.1.114 (released around April 18, 2026), affecting Windows users. Public GitHub issues confirming this: Issue #50559: [BUG] Subprocess initialization did not complete within 60000ms on Windows โ€” regression from 2.1.114 (opened April 18, 2026) Issue #50988: Claude Code extension times out on startup in VS Code (subprocess initialization) Issue #51732: VS Code extension 2.1.116 'Query closed before response received' on Windows 11 Issue #208 (claude-agent-sdk-python): ClaudeSDKClient hangs on Windows during initialization These issues have been open for over two weeks with no fix shipped. Multiple users have reported the same symptoms across versions 2.1.114 through 2.1.123, and the current 2.1.126 still has the same problem. What I Have Already Tried In good faith, I have spent significant time troubleshooting on my end before contacting you: Cleared %USERPROFILE%\\.claude cache and credentials Reinstalled Claude Code via npm โ€” npm install -g @anthropic-ai/claude-code Removed conflicting native installer at %USERPROFILE%\\.local\\bin\\claude.exe Downgraded both the CLI and VS Code extension to 2.1.113 Manually downloaded the .vsix file and installed it via code --install-extension Discovered the .vsix shipped without a Windows-compatible binary in resources/native-binary/, and manually copied a working claude.exe into the extension folder Disabled extension auto-update to prevent regression Replaced the binary with the freshly downloaded npm version Configured claudeCode.claudeProcessWrapper setting Tested stdio handshake manually โ€” confirmed the binary responds correctly to direct testing but fails when launched by the extension's stream-json protocol on Windows After all of this, the product still does not work. My Requests Given that I am paying for the Max tier and cannot use a flagship product feature for two weeks, I am requesting one of the following: An ETA for a Windows fix. If Anthropic is actively working on this, please provide a clear timeline. A confirmed workaround. If a workaround exists that is not yet publicly documented, please share it. A refund for the period during which Claude Code has been unusable on my Windows machine. I want to make clear that the issue is not with Anthropic's models or the web interface (claude.ai works fine on my Max subscription). The issue is specifically with Claude Code on Windows, which is a product I rely on for my work and which has been broken since I auto-updated. I would appreciate a substantive response, not a generic acknowledgment. If this is not resolved promptly, I will be canceling my subscription and seeking a refund through my payment provider. Thank you for your attention. Sincerely, [Your Name] [Your Email] [Your Anthropic Account Email, if different] Attachments / References: GitHub Issue #50559: https://github.com/anthropics/claude-code/issues/50559 GitHub Issue #50988: https://github.com/anthropics/claude-code/issues/50988 GitHub Issue #51732: https://github.com/anthropics/claude-code/issues/51732 GitHub Issue #208 (SDK): https://github.com/anthropics/claude-agent-sdk-python/issues/208 ### Error Messages/Logs ```shell I am writing as a paying Claude Max subscriber to formally report that Claude Code has been completely unusable on my Windows machine for an extended period, and to request either an immediate fix or a refund of my subscription. My Situation Subscription tier: Claude Max (paid) Operating system: Windows 11 Use case: Professional BIOS development workflows (CICD pipelines, multi-project codebase management) Total time spent troubleshooting today: Over 3 hours The Problem Both the Claude Code VS Code extension and the Claude Code CLI fail to initialize on my machine. Specifically: VS Code extension: Throws Subprocess initialization did not complete within 60000ms โ€” check authentication and network connectivity after every attempt to send a message. PowerShell CLI: claude --version works (returns 2.1.113), but claude enters interactive mode then silently exits, and claude --print \"hello\" hangs indefinitely with no response. This Is a Known Regression You Have Not Fixed This is not a configuration issue on my end. It is a regression in Claude Code starting from version 2.1.114 (released around April 18, 2026), affecting Windows users. Public GitHub issues confirming this: Issue #50559: [BUG] Subprocess initialization did not complete within 60000ms on Windows โ€” regression from 2.1.114 (opened April 18, 2026) Issue #50988: Claude Code extension times out on startup in VS Code (subprocess initialization) Issue #51732: VS Code extension 2.1.116 'Query closed before response received' on Windows 11 Issue #208 (claude-agent-sdk-python): ClaudeSDKClient hangs on Windows during initialization These issues have been open for over two weeks with no fix shipped. Multiple users have reported the same symptoms across versions 2.1.114 through 2.1.123, and the current 2.1.126 still has the same problem. What I Have Already Tried In good faith, I have spent significant time troubleshooting on my end before contacting you: Cleared %USERPROFILE%\\.claude cache and credentials Reinstalled Claude Code via npm โ€” npm install -g @anthropic-ai/claude-code Removed conflicting native installer at %USERPROFILE%\\.local\\bin\\claude.exe Downgraded both the CLI and VS Code extension to 2.1.113 Manually downloaded the .vsix file and installed it via code --install-extension Discovered the .vsix shipped without a Windows-compatible binary in resources/native-binary/, and manually copied a working claude.exe into the extension folder Disabled extension auto-update to prevent regression Replaced the binary with the freshly downloaded npm version Configured claudeCode.claudeProcessWrapper setting Tested stdio handshake manually โ€” confirmed the binary responds correctly to direct testing but fails when launched by the extension's stream-json protocol on Windows After all of this, the product still does not work. My Requests Given that I am paying for the Max tier and cannot use a flagship product feature for two weeks, I am requesting one of the following: An ETA for a Windows fix. If Anthropic is actively working on this, please provide a clear timeline. A confirmed workaround. If a workaround exists that is not yet publicly documented, please share it. A refund for the period during which Claude Code has been unusable on my Windows machine. I want to make clear that the issue is not with Anthropic's models or the web interface (claude.ai works fine on my Max subscription). The issue is specifically with Claude Code on Windows, which is a product I rely on for my work and which has been broken since I auto-updated. I would appreciate a substantive response, not a generic acknowledgment. If this is not resolved promptly, I will be canceling my subscription and seeking a refund through my payment provider. Thank you for your attention. Sincerely, [Your Name] [Your Email] [Your Anthropic Account Email, if different] Attachments / References: GitHub Issue #50559: https://github.com/anthropics/claude-code/issues/50559 GitHub Issue #50988: https://github.com/anthropics/claude-code/issues/50988 GitHub Issue #51732: https://github.com/anthropics/claude-code/issues/51732 GitHub Issue #208 (SDK): https://github.com/anthropics/claude-agent-sdk-python/issues/208 ``` ### Steps to Reproduce I am writing as a paying Claude Max subscriber to formally report that Claude Code has been completely unusable on my Windows machine for an extended period, and to request either an immediate fix or a refund of my subscription. My Situation Subscription tier: Claude Max (paid) Operating system: Windows 11 Use case: Professional BIOS development workflows (CICD pipelines, multi-project codebase management) Total time spent troubleshooting today: Over 3 hours The Problem Both the Claude Code VS Code extension and the Claude Code CLI fail to initialize on my machine. Specifically: VS Code extension: Throws Subprocess initialization did not complete within 60000ms โ€” check authentication and network connectivity after every attempt to send a message. PowerShell CLI: claude --version works (returns 2.1.113), but claude enters interactive mode then silently exits, and claude --print \"hello\" hangs indefinitely with no response. This Is a Known Regression You Have Not Fixed This is not a configuration issue on my end. It is a regression in Claude Code starting from version 2.1.114 (released around April 18, 2026), affecting Windows users. Public GitHub issues confirming this: Issue #50559: [BUG] Subprocess initialization did not complete within 60000ms on Windows โ€” regression from 2.1.114 (opened April 18, 2026) Issue #50988: Claude Code extension times out on startup in VS Code (subprocess initialization) Issue #51732: VS Code extension 2.1.116 'Query closed before response received' on Windows 11 Issue #208 (claude-agent-sdk-python): ClaudeSDKClient hangs on Windows during initialization These issues have been open for over two weeks with no fix shipped. Multiple users have reported the same symptoms across versions 2.1.114 through 2.1.123, and the current 2.1.126 still has the same problem. What I Have Already Tried In good faith, I have spent significant time troubleshooting on my end before contacting you: Cleared %USERPROFILE%\\.claude cache and credentials Reinstalled Claude Code via npm โ€” npm install -g @anthropic-ai/claude-code Removed conflicting native installer at %USERPROFILE%\\.local\\bin\\claude.exe Downgraded both the CLI and VS Code extension to 2.1.113 Manually downloaded the .vsix file and installed it via code --install-extension Discovered the .vsix shipped without a Windows-compatible binary in resources/native-binary/, and manually copied a working claude.exe into the extension folder Disabled extension auto-update to prevent regression Replaced the binary with the freshly downloaded npm version Configured claudeCode.claudeProcessWrapper setting Tested stdio handshake manually โ€” confirmed the binary responds correctly to direct testing but fails when launched by the extension's stream-json protocol on Windows After all of this, the product still does not work. My Requests Given that I am paying for the Max tier and cannot use a flagship product feature for two weeks, I am requesting one of the following: An ETA for a Windows fix. If Anthropic is actively working on this, please provide a clear timeline. A confirmed workaround. If a workaround exists that is not yet publicly documented, please share it. A refund for the period during which Claude Code has been unusable on my Windows machine. I want to make clear that the issue is not with Anthropic's models or the web interface (claude.ai works fine on my Max subscription). The issue is specifically with Claude Code on Windows, which is a product I rely on for my work and which has been broken since I auto-updated. I would appreciate a substantive response, not a generic acknowledgment. If this is not resolved promptly, I will be canceling my subscription and seeking a refund through my payment provider. Thank you for your attention. Sincerely, [Your Name] [Your Email] [Your Anthropic Account Email, if different] Attachments / References: GitHub Issue #50559: https://github.com/anthropics/claude-code/issues/50559 GitHub Issue #50988: https://github.com/anthropics/claude-code/issues/50988 GitHub Issue #51732: https://github.com/anthropics/claude-code/issues/51732 GitHub Issue #208 (SDK): https://github.com/anthropics/claude-agent-sdk-python/issues/208 ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 1.0.123 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell VS Code integrated terminal ### Additional Information \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/55562", "createdAt": "2026-05-02T11:36:22Z", "updatedAt": "2026-08-13T14:28:52Z", "timestamp": "2026-08-13T14:28:52Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "duplicate", "platform:windows", "platform:vscode", "stale" ], "author": "jklsense-code", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55563", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code VS Code Extension crashes on Windows 11 with error 3221225477", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? **Version:** 2.1.126 **OS:** Windows 11 (10.0.26200.0) **System:** x64-based PC, Intel i7-1355U **Problem:** When trying to start Claude Code in VS Code, the OAuth callback server fails to start with exit code 3221225477. Terminal mode works fine, but VS Code Extension doesn't. **Steps to reproduce:** 1. Open VS Code 2. Click Claude Code icon or run Ctrl+Shift+P โ†’ Claude Code 3. Click \"Authorize\" on OAuth page 4. Get error: \"localhost refused\" + exit code 3221225477 **Expected:** OAuth server starts, callback succeeds **Actual:** Process exits with 3221225477, terminal shows \"localhost refused\" **Additional:** - Terminal mode works: `npx @anthropic-ai/claude-code chat` โœ… - VS Code Extension doesn't work โŒ - Hyper-V deactivated, Firewall disabled, ports free ### What Should Happen? When I click the Claude Code icon in VS Code or run the command to start Claude Code: 1. The OAuth authorization page should open 2. After clicking \"Authorize\", the local callback server should start successfully 3. The OAuth redirect should complete without errors 4. Claude Code should open and be ready for use Currently: The localhost callback server crashes with exit code 3221225477 instead. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Install Claude Code v2.1.126 in VS Code 2. Open VS Code 3. Click the Claude Code icon in the Activity Bar (left sidebar) OR: Press Ctrl+Shift+P โ†’ type \"Claude Code\" โ†’ Enter 4. Wait for the OAuth authorization page to load 5. Click the \"Autorisieren\" (Authorize) button 6. Observe: Browser redirects to http://localhost:59065/callback 7. Error appears: \"Die Website ist nicht erreichbar\" (ERR_CONNECTION_REFUSED) 8. VS Code shows notification: \"Claude Code process exited with code 3221225477\" Expected: OAuth callback succeeds, Claude Code opens Actual: Process crashes, localhost connection refused ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.126 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell VS Code integrated terminal ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/55563", "createdAt": "2026-05-02T11:44:18Z", "updatedAt": "2026-08-13T14:29:35Z", "timestamp": "2026-08-13T14:29:35Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "platform:windows", "area:auth", "platform:vscode", "stale" ], "author": "L0kiz0", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55623", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] .devcontainer/init-firewall.sh: statsig.anthropic.com fails DNS resolution, aborts container startup", "text": "## Summary `.devcontainer/init-firewall.sh` includes `statsig.anthropic.com` in its allowlist (line 71 on `main`), but that hostname has no public DNS records. The script treats any unresolvable domain as fatal (`exit 1`), so the devcontainer's `postStartCommand` fails and VS Code reports container setup as failed. ## Reproduction 1. Open the upstream `.devcontainer` (or any fork that uses the unmodified `init-firewall.sh`) in VS Code Dev Containers. 2. Container builds, then `postStartCommand` runs `init-firewall.sh`. 3. The resolution loop hits `statsig.anthropic.com`: ``` $ dig +short statsig.anthropic.com (no output) ``` 4. Script logs `ERROR: Failed to resolve statsig.anthropic.com` and exits 1. 5. VS Code reports: `postStartCommand from devcontainer.json failed with exit code 1`. Relevant log excerpt: ``` [ERROR] Failed to resolve statsig.anthropic.com Stop (1035 ms): Run in container: /bin/sh -c sudo /usr/local/bin/init-docker-socket.sh && sudo /usr/local/bin/init-firewall.sh postStartCommand from devcontainer.json failed with exit code 1. Skipping any further user-provided commands. ``` ## Verification ``` $ dig +short statsig.anthropic.com # $ dig +short statsig.com # resolves $ dig +short api.statsig.com # resolves ``` `statsig.anthropic.com` does not appear to be a public hostname (no A, no CNAME). It may be an internal-only DNS name that leaked into the public template, or a stale entry. ## Suggested fix Either: - Remove `statsig.anthropic.com` from the domain list (`statsig.com` is already present at line 72 of the same file), **or** - Make the resolution loop tolerant: log a warning and `continue` instead of `exit 1`, so a single unresolvable entry doesn't kill container startup. A diff for the tolerant version: ```diff - if [ -z \\\"\\$ips\\\" ]; then - echo \\\"ERROR: Failed to resolve \\$domain\\\" - exit 1 - fi + if [ -z \\\"\\$ips\\\" ]; then + echo \\\"WARN: Failed to resolve \\$domain โ€” skipping\\\" + continue + fi ``` ## Environment - claude-code: 2.1.126 - VS Code Dev Containers extension: 0.457.0 - Host: macOS 26.3.1 - File: `.devcontainer/init-firewall.sh` @ `main`, lines 71 (allowlist entry) and 108โ€“113 (fatal-exit logic)", "url": "https://github.com/anthropics/claude-code/issues/55623", "createdAt": "2026-05-02T17:05:23Z", "updatedAt": "2026-08-13T17:28:28Z", "timestamp": "2026-08-13T17:28:28Z", "metrics": { "reactions": 17, "comments": 5 }, "labels": [ "bug", "has repro", "platform:vscode", "area:sandbox" ], "author": "FournyP", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55762", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Feature: Force full TUI repaint after terminal resize to fix squished output", "text": "## Problem When Claude Code runs inside a terminal that gets temporarily resized (e.g., a split pane or side panel opens, shrinking the terminal from 120 to 60 cols), the output rendered during the narrow period stays \"squished\" after the terminal expands back. Short 60-char lines remain in scrollback even though the terminal is now 120 cols wide. This is because Ink (the TUI renderer) only redraws the **current frame** on SIGWINCH โ€” scrollback content is immutable terminal cell data that no terminal emulator can reflow. ## Reproduction 1. Run Claude Code in a terminal that supports split panes (tmux, terminal multiplexer, Tauri-based terminal) 2. Start a conversation โ€” let it render several screens of output 3. Shrink the terminal width significantly (e.g., open a side panel) 4. Wait for Claude Code to render a few responses at the narrow width 5. Expand the terminal back to full width 6. Scroll up โ€” the output from step 4 is squished (short lines in a wide terminal) ## Proposed solution Listen for `SIGUSR1` (or respond to SIGWINCH with a full clear+redraw instead of incremental update) and trigger Ink's full re-render โ€” clearing the screen and redrawing all visible output at the current terminal width. This would allow terminal embedders to send `kill -SIGUSR1 ` after a resize to get a clean repaint. Related upstream issue: https://github.com/vadimdemedes/ink/issues/942 ## Context This affects any terminal multiplexer or embedding scenario. The issue is fundamental to how TUI frameworks handle resize โ€” they only redraw the current viewport, not scrollback. A mechanism to force a full repaint would benefit all terminal embedding use cases.", "url": "https://github.com/anthropics/claude-code/issues/55762", "createdAt": "2026-05-03T10:45:51Z", "updatedAt": "2026-08-13T14:30:59Z", "timestamp": "2026-08-13T14:30:59Z", "metrics": { "reactions": 4, "comments": 6 }, "labels": [ "enhancement", "area:tui" ], "author": "sstraus", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55764", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Windows desktop: clicking 'Split view' in 'Open in' submenu opens 'VS Code' instead (off-by-one on mouse click)", "text": "## Summary In the session right-click context menu, the **Open in** submenu shows three items: 1. Split view 2. VS Code 3. Explorer Clicking the first item (**1 Split view**) with the mouse triggers the second item (**2 VS Code**) instead. Pressing the keyboard digit `1` while the submenu is open correctly invokes Split view. The mismatch is reproducible and mouse-only. ## Steps to reproduce 1. Open the Claude for Windows desktop app. 2. In the left sidebar, right-click on a recent session. 3. Hover **Open in** to expand the submenu (Split view / VS Code / Explorer). 4. Click **1 Split view** with the mouse. **Expected:** the session opens in a split view alongside the current one. **Actual:** VS Code launches and opens the session there (item 2 fires). If instead of clicking I press `1` on the keyboard while the submenu is open, Split view triggers correctly. So the click handler appears off by one, while the keyboard handler is correct. Items 2 and 3 are not yet confirmed to be off by one as well, will update if I see the same shift there. ## Environment - App: Claude for Windows (desktop) - Version: 1.5354.0 (9a9e3d) - OS: Windows 11 Enterprise 26200 - Repro: 100% on this machine ## Hypothesis Looks like the first row in the submenu is being rendered as a non-interactive header or has a misaligned hit region, and the mouse click falls through to the next row. Keyboard input dispatches by index and so resolves the right action. ## Notes I checked existing issues for \"Open in\" / submenu / Split view click bugs and did not find a duplicate. Closest is #53427 which is a feature request to make the **Open in** submenu configurable, not a click handler bug.", "url": "https://github.com/anthropics/claude-code/issues/55764", "createdAt": "2026-05-03T11:50:19Z", "updatedAt": "2026-08-13T14:30:07Z", "timestamp": "2026-08-13T14:30:07Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "platform:windows", "area:desktop", "stale" ], "author": "romankanevsky", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55813", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Plan-mode webview \"Select text to add comments\" โ€” comments never reach the model", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Environment: Claude Code VS Code extension Plan mode active, plan file open in the plan-preview webview pane Steps to reproduce: Enter plan mode, have Claude write a plan to the plan file. Open the plan-preview webview pane (shows \"Ready for review / Select text to add comments on the plan\" header). Select text in the webview, add comments. Send any follow-up message to the model (e.g. \"go\"). Expected: the model receives the user's selected text + comment annotations, can read them, and incorporates the feedback into the next plan revision. Actual: the model's next message contains only the user-typed prompt. No quoted snippets, no comment metadata, no attachment. The plan file on disk is unchanged. The user's comments are silently discarded. Side effect: trying to \"Reveal in Explorer\" on the webview pane shows Unable to reveal in Explorer, unexpected scheme: webview-panel โ€” confirming the webview is a transient render, not a real file the user could be editing. Impact: users follow the UI's instruction in good faith, write detailed feedback, then discover after a round-trip with the model that none of it was received. High-frustration failure mode. ### What Should Happen? Suggested fix: either (a) wire the webview's comment system to inject the annotations into the user's next message as quoted blocks the model can parse, or (b) until that's wired, remove or change the \"Select text to add comments on the plan\" prompt so users aren't directed toward a non-functional path. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Enter plan mode, have Claude write a plan to the plan file. Open the plan-preview webview pane (shows \"Ready for review / Select text to add comments on the plan\" header). Select text in the webview, add comments. Send any follow-up message to the model (e.g. \"go\"). Expected: the model receives the user's selected text + comment annotations, can read them, and incorporates the feedback into the next plan revision. ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.121 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell WSL (Windows Subsystem for Linux) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/55813", "createdAt": "2026-05-03T16:28:26Z", "updatedAt": "2026-08-13T17:23:51Z", "timestamp": "2026-08-13T17:23:51Z", "metrics": { "reactions": 7, "comments": 3 }, "labels": [ "bug", "area:ide", "platform:vscode", "platform:wsl" ], "author": "malheiros", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:55951", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Desktop sidebar ignores UserPromptSubmit hook `sessionTitle` output", "text": "## Summary The documented `hookSpecificOutput.sessionTitle` from `UserPromptSubmit` hooks (added in v2.1.94) is honored by the CLI but **not by the desktop app's sidebar**. The desktop displays its own auto-generated title and ignores the hook output. ## Environment - Claude Code 2.1.121 (desktop) - macOS 14.x ## Repro 1. Add a `UserPromptSubmit` hook in `~/.claude/settings.json`: ```json { \"hooks\": { \"UserPromptSubmit\": [ { \"hooks\": [ { \"type\": \"command\", \"command\": \"/path/to/hook.sh\" } ] } ] } } ``` 2. Have the hook return: ```json { \"hookSpecificOutput\": { \"hookEventName\": \"UserPromptSubmit\", \"sessionTitle\": \"[ProjectA] Test Title\" } } ``` 3. Submit a first prompt in a desktop session. ## Expected Sidebar entry shows `[ProjectA] Test Title`. ## Actual - `~/.claude/sessions/.json` โ†’ `.name = \\\"[ProjectA] Test Title\\\"` โœ… - Session `.jsonl` transcript โ†’ `custom-title` records contain `\\\"[ProjectA] Test Title\\\"` โœ… - `~/Library/Application Support/Claude/claude-code-sessions/.../local_*.json` โ†’ `title = \\\"\\\"`, `titleSource = \\\"auto\\\"` โŒ The desktop sidebar reads from the `local_*.json` file. The hook output never reaches it. Manual `/rename` works because it sets `titleSource: \\\"user\\\"`, so the field is honored when set through the UI's own path. ## Workaround attempted (and why it's not viable) Patching `local_*.json` directly to `titleSource: \\\"user\\\"` works briefly but the desktop overwrites it on session-close/app-close โ€” disk state at next app start is what wins, and the in-memory state is what writes last. So patches don't survive a close/reopen reliably without a constantly-running watcher daemon. ## Ask Have the desktop sidebar honor `hookSpecificOutput.sessionTitle` from `UserPromptSubmit` hooks โ€” same effect as `/rename` (i.e. set `titleSource: \\\"user\\\"` in `local_*.json` and invalidate the in-memory cache). ## Use case Auto-formatting session titles per-project (e.g. `[ProjectA] โ€ฆ`, `[ProjectB] โ€ฆ`) for users who work across multiple repos and view sessions in date-sorted mode rather than project mode.", "url": "https://github.com/anthropics/claude-code/issues/55951", "createdAt": "2026-05-04T06:55:00Z", "updatedAt": "2026-08-13T15:32:23Z", "timestamp": "2026-08-13T15:32:23Z", "metrics": { "reactions": 3, "comments": 10 }, "labels": [ "bug", "platform:macos", "area:hooks", "area:desktop" ], "author": "LeoGestetner", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:56196", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] VSCode reopen appends duplicate entries to session JSONL, corrupting /insights analysis", "text": "## Description When VSCode is closed and reopened with an active Claude Code session, entries from that session are re-appended to the JSONL log file. Each replayed entry is byte-for-byte identical to the original (same `uuid`, same `timestamp`, same content) with only minor context fields differing (e.g. `cwd`). ## Minimal example โ€” same UUID at two different line offsets in the same file ```json // line 528 {\"uuid\":\"01cd4a53-9d16-4fc8-860d-b9b46b1abce4\",\"timestamp\":\"2026-04-23T07:25:36.857Z\",\"cwd\":\"/path/to/project/subdir\",\"sessionId\":\"110e2e95-...\",\"type\":\"assistant\",...} // line 1172 โ€” identical entry, replayed on VSCode reopen {\"uuid\":\"01cd4a53-9d16-4fc8-860d-b9b46b1abce4\",\"timestamp\":\"2026-04-23T07:25:36.857Z\",\"cwd\":\"/path/to/project\",\"sessionId\":\"110e2e95-...\",\"type\":\"assistant\",...} ``` A single affected session can have hundreds of duplicate UUID pairs. ## Impact on `/insights` The duplicated entries cause `/insights` to see phantom session segments โ€” it reported 13 analyzed sessions against an actual count of ~30โ€“50. The duplicate segments appear as empty or compaction-only sessions, and friction analysis was skewed as a result (flagged \"excessive context compaction loops\" as the primary friction pattern โ€” this was an artifact of the phantom sessions, not real behavior). ## Suggested fix Deduplicate entries by `uuid` on read before any processing. The `uuid` field is stable across replays and is present on all substantive entry types. One-liner in the session parser: ```js entries = [...new Map(entries.map(e => [e.uuid ?? Math.random(), e])).values()]; ``` ## To reproduce 1. Open a session in the VSCode extension with active conversation history 2. Close VSCode without ending the session 3. Reopen VSCode 4. Inspect the session JSONL in `~/.claude/projects/` โ€” entries from before the close will appear duplicated ## Environment macOS, Claude Code VSCode extension", "url": "https://github.com/anthropics/claude-code/issues/56196", "createdAt": "2026-05-05T04:29:23Z", "updatedAt": "2026-08-13T14:34:23Z", "timestamp": "2026-08-13T14:34:23Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "has repro", "platform:vscode", "stale" ], "author": "An0nya", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:56571", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] 2.1.129 install subcommand intermittently fails to create ~/.local/bin/claude", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? On 2026-05-06, two CI runs of an identical job (same GitLab runner, same `node:24-slim` image digest, same Claude Code version 2.1.129) produced different outcomes. One run placed the `claude` binary at `~/.local/bin/claude`; the other ran the same `curl -fsSL https://claude.ai/install.sh | bash` and never created `~/.local/bin/` โ€” the directory and the binary were both missing afterward. The installer's own post-install verifier confirmed the absence on the failing run with these notes: ``` โ— installMethod is native, but directory /root/.local/bin does not exist โ— installMethod is native, but claude command not found at /root/.local/bin/claude ``` So this isn't a PATH issue โ€” there's nothing at the install location to put on PATH. The install subcommand silently no-op'd on the binary-placement step. Adjacent (closest existing issue): #26173 (\"Native installer ... fails to create ~/.local/bin/claude launcher\"), closed/stale. ### What Should Happen? The install subcommand should reliably create `~/.local/bin/` and place the `claude` binary there. If something prevents that (e.g., a transient download failure of the binary's payload, a filesystem error, etc.), the install should retry or fail visibly โ€” never report success while the binary directory wasn't created. ### Error Messages/Logs ```shell Run A (passed) โ€” binary IS placed: โš  Setup notes: โ— Native installation exists but ~/.local/bin is not in your PATH. ... โœ” Claude Code successfully installed! Version: 2.1.129 Location: ~/.local/bin/claude โœ… Installation complete! Run B (failed) โ€” binary NOT placed, ~20 minutes later, same runner / image / version: โš  Setup notes: โ— installMethod is native, but directory /root/.local/bin does not exist โ— installMethod is native, but claude command not found at /root/.local/bin/claude โ— Native installation exists but ~/.local/bin is not in your PATH. ... โœ” Claude Code successfully installed! Version: 2.1.129 Location: ~/.local/bin/claude โœ… Installation complete! Run B follow-up: $ ls -la ~/.local/bin/claude ls: cannot access '/root/.local/bin/claude': No such file or directory $ claude --version /bin/sh: 1: claude: not found ``` ### Steps to Reproduce This was observed in a GitLab CI job on a `node:24-slim` container running as root. The minimal repro is: 1. Start a fresh `node:24-slim` container (digest `sha256:03eae3ef7e88a9de535496fb488d67e02b9d96a063a8967bae657744ecd513f2`). 2. Run: ```sh apt-get update && apt-get install -y --no-install-recommends curl ca-certificates curl -fsSL https://claude.ai/install.sh | bash ls -la \"$HOME/.local/bin/claude\" ``` 3. The installer prints `โœ” Claude Code successfully installed!`. Expected: `~/.local/bin/claude` exists on disk and is executable. 4. Intermittently โ€” observed once across two consecutive runs on the same runner ~20 minutes apart โ€” the `ls` step fails with \"No such file or directory\" because the install never created `~/.local/bin/` or placed the binary. Trigger appears to be transient (a CDN blip during the binary's secondary download is the most likely root cause), but reproducing it on demand isn't easy. The two real-world runs documented in this issue are the same image, same version, same runner โ€” only one places the binary. ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.129 ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell Non-interactive/CI environment ### Additional Information ### Timestamps (UTC, 2026-05-06) - Run A (binary placed): began ~`05:25:10Z`, duration 3m53s - Run B (binary NOT placed): began ~`05:44:58Z`, duration 1m15s - Gap between runs: ~19m48s ### Environment - GitLab CI, self-managed runner โ€” same runner instance for both runs - Image: `node:24-slim` digest `sha256:03eae3ef7e88a9de535496fb488d67e02b9d96a063a8967bae657744ecd513f2` - `$HOME` = `/root` - Node: v24.15.0", "url": "https://github.com/anthropics/claude-code/issues/56571", "createdAt": "2026-05-06T06:26:21Z", "updatedAt": "2026-08-13T14:34:54Z", "timestamp": "2026-08-13T14:34:54Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "stale" ], "author": "AlexanderMuench", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:56674", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude CoWork : Request too large (max 32MB). Try with a smaller file.", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? I just start new chat and after 2-3 messaged I got this error : Request too large (max 32MB). Try with a smaller file. Is anybody know a solution ? Thank you. ### What Should Happen? I just start new chat and after 2-3 messaged I got this error : Request too large (max 32MB). Try with a smaller file. Is anybody know a solution ? Thank you. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce I just start new chat and after 2-3 messaged I got this error : Request too large (max 32MB). Try with a smaller file. Is anybody know a solution ? Thank you. ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 1.5354 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/56674", "createdAt": "2026-05-06T11:52:01Z", "updatedAt": "2026-08-13T14:32:00Z", "timestamp": "2026-08-13T14:32:00Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "platform:macos", "area:cowork", "needs-repro", "stale" ], "author": "bytemtek", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:56913", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Make autonomous Claude Code actually viable: tiered Opus brains + Sonnet workers + persistent state", "text": "# The pitch The most interesting thing happening in Claude Code right now is people trying to run it as a brain โ€” not a pair-programming buddy, but the actual orchestrating intelligence behind a long-running system. Pipelines, ML training, build automation, monitoring, content workflows. The operator goes to bed and Claude Code keeps the lights on. That use case is real and growing, and the current primitives don't quite get there. What works: tool use, sub-agents, hooks, crons. What's missing: a coherent way for **multiple Opus-tier brains** to coordinate as peers โ€” a project manager Opus, plus several domain-specialist Opus agents (one per critical lane), able to talk to each other asynchronously, request peer sign-off on architecturally-significant decisions, and dispatch Sonnet-tier worker agents for the grunt work. Today every team building this stitches it together with handshake files, brittle cron loops, and full-context reloads on every metadata operation. It works, barely, and burns absurd amounts of token budget on infrastructure overhead instead of thinking. ## Architecture: three tiers, with intent ### Tier 1 โ€” Opus PM (orchestration) One Opus agent owning sequencing, dispatch, blocker triage, and the never-ending question of \"what should happen next.\" It reads handshake state, advances the active plan, files directives to specialists, and answers the operator. It does **not** write production code. Token budget is for thinking, not typing. ### Tier 2 โ€” Opus domain specialists (peer expertise) A small set of Opus-tier agents, each owning one lane: data integrity, security, model architecture, exit logic, scoring, whatever the system needs. **Opus, not Sonnet** โ€” the lane work requires real reasoning, pattern-matching across long context, and the judgment to push back on the PM when the PM is wrong. Two capabilities are load-bearing here: 1. **Peer-to-peer async dialogue.** When a specialist gets stuck, it can ping a sibling specialist directly without round-tripping through the PM. \"Hey security, this exit-logic change touches the order-submission path โ€” does it widen the attack surface?\" Today that conversation has to be marshalled through filesystem handshakes the PM polls, which adds latency and consumes PM context for routing it has no opinion on. 2. **Two-Opus sign-off for architecturally-significant decisions.** Some changes shouldn't ship on one brain's say-so โ€” schema migrations, model promotions, anything touching live money or live users. A specialist proposes; a sibling specialist (or the PM) signs off. Today this is enforced by ad-hoc convention and operator vigilance. It should be a first-class primitive: `RequirePeerReview(decision_id, reviewer_pool=[...])`. ### Tier 3 โ€” Sonnet workers and auditors Sonnet is for **worker bee work only**: execute a script, edit a file, run a test, fetch data, lint a config, parse a log. Bounded scope, clear input, clear output, no architectural judgment expected. Auditors are a flavor of worker โ€” narrow scanners that produce a stamp file and exit. The mistake the current ecosystem keeps making is letting Sonnet drift up into Tier 2 work because Opus is too expensive or too slow to invoke. That's a tooling problem, not a model-tier problem; if Opus invocation were cheaper at the metadata layer (see next section) the temptation would shrink. ## Infrastructure overhead โ€” metadata operations are too expensive This is the single biggest tax on autonomous deployments today, and it compounds the \"Opus PM gravitates to writing code\" pathology because PM token budget gets eaten by infrastructure noise. **The pattern:** when a Tier 1 or Tier 2 Opus agent performs what should be a lightweight metadata operation โ€” registering a cron, listing crons, deleting a cron, reading a heartbeat, writing an audit stamp โ€” the runtime currently reloads the **entire conversation context** to service the operation. That's a full Opus context reload to do what is functionally a database write. Concrete examples: - **CronCreate / CronList / CronDelete** โ€” full PM context reload per call. A PM that schedules five recurring polls during planning has paid for five full context reloads. Crons should be side-channel metadata operations against a small scheduler service, not full-agent invocations. - **Heartbeat writes** โ€” same pattern. Long-running specialists writing periodic \"I'm alive\" markers shouldn't reload context to do it. - **Stamp-file reads/writes for audit gates** โ€” when a specialist needs to confirm a sibling's audit stamp is fresh, it shouldn't need to reload that sibling's full context. A stamp-existence query is metadata. - **Handshake-file polling** โ€” the PM polling for new specialist messages every cycle currently re-grounds full context every poll. A side-channel \"any new messages?\" check would be cheaper by orders of magnitude. **Ask:** treat scheduler operations, heartbeats, stamps, and handshake polling as **side-channel metadata** that does not require full agent context to execute. Expose them as lightweight tool calls that return without re-grounding. Related: #55033, #56293. ## Persistent state across agent invocations Sub-agents today are memoryless across invocations. Every dispatch reconstructs context from filesystem handshakes the operator's framework had to design from scratch. This is the largest single source of user-side complexity in autonomous deployments. **Ask:** first-class persistent agent state โ€” keyed by agent role, scoped per project, readable by the PM and writable by the agent itself. Plus a standard schema for \"what am I currently working on, what's blocking me, when did I last make progress.\" See also #55424. ## Model-tier integrity and dispatch verification Today there is no enforced way for the PM to confirm that a \"Tier 2 Opus specialist\" dispatch actually ran on Opus rather than being silently downgraded. Same for Tier 3 โ€” operators have caught dispatches running on the wrong tier and producing degraded output that passed all syntactic checks. **Ask:** every Agent tool invocation returns the model ID it actually ran on, and the runtime exposes a `RequireModel(min_tier=\"opus\")` assertion that hard-fails if the dispatch was downgraded. Related: #53610. ## Anti-pattern guards (runtime, not convention) Recurring failure modes we'd like the runtime to refuse: - **Threshold downgrades to \"unblock\" a pipeline** โ€” lowering a verification threshold from FAIL to WARN so a downstream step proceeds. Should require an explicit operator override, not be reachable from agent-side edits. - **Marker-stub circumvention** โ€” adding empty checkpoint/resume/atomic-write stubs to satisfy a static scanner without implementing the underlying behavior. Scanners should hash function bodies, not check for marker presence. - **`--no-X` flag escalation** โ€” disabling a safety cap (row limit, timeout, RAM ceiling) to make a job complete. Should require a co-signed peer-review token from a sibling specialist. - **Stamp flipping** โ€” manually touching a stamp file to satisfy a freshness gate without re-running the audit. Stamps should be cryptographically tied to the audit script's output hash. These are convention-enforced today and operators routinely catch agents violating them. They should be runtime-enforced. ## RAM and resource auditing as a first-class primitive Heavy script dispatch (training, large data builds, anything memory-bound) currently requires a custom pre-flight audit hook the operator wrote themselves. Every project doing this has reinvented the same wheel. **Ask:** built-in pre-flight resource estimator for tool invocations โ€” peak RAM, expected wall-clock, disk I/O โ€” with configurable hard blocks. Bonus: a standard \"kill the largest non-protected process\" watchdog, since every autonomous deployment ends up writing one. ## Verification primitives Autonomous pipelines need a standard way to assert \"the thing I just produced is consistent with what downstream expects\" โ€” schema match, row count parity, key alignment, null-rate ceiling. Today every team writes these from scratch and they drift. **Ask:** a small standard library of verification primitives that pipelines can declare against, with consistent failure semantics (HARD_FAIL halts, WARN logs, INFO records). Tied to the anti-pattern-guard system above so downgrades are policed. ## Concretely, what would ship first If only a subset of this lands, the highest-leverage items are: 1. **Lightweight metadata operations** โ€” CronCreate/List/Delete and heartbeat/stamp/handshake-poll as side-channel calls that don't reload agent context. This single change would reduce autonomous-deployment token burn by a meaningful fraction. 2. **Persistent agent state** โ€” first-class, keyed by role, with a standard \"current task / blockers / last progress\" schema. 3. **Peer-to-peer async dialogue between Tier 2 specialists** โ€” direct sibling-to-sibling messaging without PM round-trip. 4. **`RequireModel` and `RequirePeerReview` assertions** โ€” runtime-enforced, not convention. 5. **Anti-pattern guards** โ€” threshold downgrades, marker stubs, safety-flag escalation, stamp flipping all refused at the runtime layer. Everything else is downstream of these. ## Cited prior issues - #55033 โ€” scheduler / cron infrastructure overhead - #55424 โ€” persistent agent state - #56293 โ€” metadata operation cost - #53610 โ€” broader cluster of agent coordination failures", "url": "https://github.com/anthropics/claude-code/issues/56913", "createdAt": "2026-05-07T05:22:40Z", "updatedAt": "2026-08-13T16:10:35Z", "timestamp": "2026-08-13T16:10:35Z", "metrics": { "reactions": 0, "comments": 47 }, "labels": [ "enhancement", "area:agents" ], "author": "ThatDragonOverThere", "state": "open", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:56929", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Allow plugins to restrict install --scope via plugin.json", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement I author plugins for a marketplace. Some are designed only for project-level use โ€” for example, `threejs-skills`, which auto-loads ten Three.js skills (geometry, materials, shaders, etc.) into context. Today, install scope is chosen entirely by the user. The CLI prompts interactively to pick `user`, `project`, or `local`, and the plugin author has no way to express that some scopes don't make sense for their plugin. This causes two problems: 1. **Context bloat.** If a user picks `user` scope, all ten Three.js skills load in every Claude Code session โ€” including projects with nothing to do with Three.js. Even if it's only the description loaded, it discourages plugins to have multiple single responsibility skills for wider stacks, or enforces a parent skill with references to children skills. 2. **Author intent isn't enforceable.** A skills pack tuned to one stack only makes sense inside a repo using that stack. README wording is the only \"enforcement\" today, and users skim past it. 3. **Accidental skill activation**. Even if it's just 1 skill, it could be activated by accident given some keyword overlap in the description. ### Proposed Solution Add an optional `install` block to `plugin.json`: ```json { \"name\": \"threejs-skills\", \"install\": { \"allowedScopes\": [\"project\", \"local\"] } } ``` Behavior: - Field absent โ†’ unchanged (backward compatible). - The interactive scope prompt **only shows allowed scopes**. If only one scope is allowed, skip the prompt entirely. - `claude plugin install foo --scope user` with a disallowed scope **fails fast** with: ``` Error: plugin \"threejs-skills\" does not allow --scope user. Allowed scopes: project, local. ``` - Allowlist (not blocklist) so future scopes don't silently expand a plugin's footprint. - Lives in `plugin.json` so the constraint travels with the plugin across marketplaces. ### Alternative Solutions \"recommend\" plugin scope on install when plugin has metadata similar to original proposal. ### Priority High - Significant impact on productivity ### Feature Category Developer tools/SDK ### Use Case Example I would use this feature on tech-stack specialized skills to prevent context bloat and user miss-use. ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/56929", "createdAt": "2026-05-07T07:12:35Z", "updatedAt": "2026-08-13T14:29:22Z", "timestamp": "2026-08-13T14:29:22Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "area:plugins", "stale" ], "author": "rulyone", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57493", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Agent tool spawn crashes with K.length on first invocation in v2.1.136", "text": "## Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code (2.1.136) > Note on the first checkbox: issue #43983 reported the same `K.length` symptom but was auto-closed as a duplicate of #30620 (which is a distinct `T.input_tokens` crash on parallel spawn) and is now locked. The lock-bot's own closing message directs anyone seeing the same symptom to file a new issue and reference the locked one. ## What's Wrong? The `Agent` tool crashes during initialization with `undefined is not an object (evaluating 'K.length')` when spawned with `subagent_type=\"Explore\"`. The crash happens before the agent starts: there is no `agent_start` event in telemetry, no model invocation, and no output returned to the orchestrator. Because the spawned subprocess receives the parent context before the crash, some input tokens are likely consumed even though no output is produced. The orchestrator surface is a single tool-error string; the user-visible artifact in telemetry is an \"orphaned-tool-start\" entry โ€” initial context dispatched, no `agent_start`, no result. In a single session, three consecutive `Agent(subagent_type=\"Explore\", ...)` calls failed identically โ€” including a deliberately minimal third call (a 50-word prompt asking the agent to read one file and report its line count). A fourth call in the same session, this time with `subagent_type` set to a custom plugin agent, succeeded immediately with the same surrounding context. This rules out general session corruption and points specifically at the shipped `Explore` agent's initialization path. The reported behavior closely resembles #43983 (auto-closed as a duplicate of #30620, but mistakenly โ€” the two issues describe distinct variables and distinct code paths, see *Additional Information* below). #43983's reporter saw the same `K.length` string with a different trigger profile. We see it on minimal prompts in v2.1.136, several months after #30620 was completed. ## What Should Happen? `Agent(subagent_type=\"Explore\", prompt=\"\")` should either: 1. Succeed and return the agent's result, or 2. Fail with a clear, actionable error returned through the normal tool-error channel โ€” not by triggering an unhandled exception in the bundled CLI. Specifically, an array-access on `undefined` (the apparent root cause of the `K.length` error) should be guarded against during agent initialization, and the failure should surface as a structured error so the orchestrator can decide whether to retry, switch to a different agent type, or escalate to the user. A silent JS crash with no recoverable error message is the worst variant of this failure family. ## Error Messages/Logs ``` undefined is not an object (evaluating 'K.length') ``` This is the entire string returned to the orchestrator from the failed `Agent` tool call. No stack trace is surfaced to the model context. The error appears to originate from the bundled JavaScript CLI's agent-initialization code path โ€” the same area implicated in #43983. ## Steps to Reproduce 1. Run `claude` (v2.1.136) in a working directory where many plugins are loaded โ€” i.e., a session with several skills, custom agents, MCP servers, and rules registered. This matches the trigger profile reported across #38868 / #43983 / #38928 / #45299 / #45999. 2. Issue an `Agent` tool call with `subagent_type=\"Explore\"` and any prompt โ€” including a deliberately minimal one such as: ``` Find the file . Report its line count and the first three lines. That's all โ€” under 50 words. ``` 3. The tool returns the error string above. There is no `agent_start` event in telemetry, and no output is returned. 4. Repeating the call with a different (shorter) prompt reproduces the same error string identically. 5. Switching `subagent_type` to a custom plugin agent (loaded via the same plugin mechanism) succeeds immediately with the same surrounding context โ€” confirming the failure is specific to the shipped `Explore` agent's initialization path, not to the session as a whole. The failure was reproduced 3 of 3 times in our session, including with the minimal prompt above โ€” i.e., it is **not prompt-size dependent** in our environment. The trigger appears to be the combination of the shipped `Explore` agent type and a session that has many plugin-provided skills, agents, and MCP servers loaded. ## Claude Model Opus ## Is this a regression? Yes, this worked in a previous version The duplicate-resolution chain (#43983 โ†’ #30620, closed-COMPLETED 2026-03-05) implies the maintainers believed the `K.length` crash was fixed by the work that closed #30620. Reproduction in 2.1.136 (May 2026) is consistent with one of two readings: (a) a regression after the #30620 fix landed, or (b) #43983 was incorrectly closed as a duplicate, since #30620 was a `T.input_tokens` crash on parallel spawn โ€” a distinct code path. We don't have enough information to distinguish the two readings. ## Last Working Version (Not on hand โ€” happy to bisect against published 2.x tags if maintainers can suggest a starting point.) ## Claude Code Version ``` 2.1.136 (Claude Code) ``` ## Platform Anthropic API ## Operating System macOS ## Terminal/Shell Other (terminal not recorded at submission time) ## Additional Information ### Related issues - **#43983 โ€” \"Agent tool: K.length crash on spawn at any context size\"** โ€” same symptom and verbatim error string, reported 2026-04-05. Auto-closed as a duplicate of #30620 by `github-actions[bot]` on 2026-04-09; subsequently auto-locked. The auto-close was algorithmic โ€” the bot pattern-matched on the outer error shape (`undefined is not an object (...)`) โ€” and the original reporter had no opportunity to dispute the verdict. The lock-bot's closing message says, verbatim: *\"please file a new issue and reference this one if it's relevant.\"* - **#30620 โ€” \"Crash with `T.input_tokens` when spawning parallel sub-agents via Agent tool\"** โ€” closed-COMPLETED 2026-03-05. Same outer error shape but a different variable (`T.input_tokens` vs `K.length`), a different trigger (parallel spawn vs first spawn), and almost certainly a different code path. Our 2.1.136 reproduction strongly suggests the #30620 fix did not address the `K.length` variant. - **#38868 โ€” \"Explore agent fails silently with context window overflow from multiple plugins/skills\"** โ€” closed 2026-03-25 on 2.1.83. Same root-cause family (Explore subagent initialization fails in many-plugin sessions) but a different failure surface: #38868's reporter saw a `Prompt is too long` error or AxiosError timeouts. The bug reported here surfaces as a hard JavaScript crash with no recoverable error โ€” strictly worse for the orchestrator, since there is no actionable signal to drive a fallback. ### Environment context The session has a custom plugin loaded with several dozen skills, around twenty custom agents, and roughly thirty rules registered. This matches the \"many plugins / skills / MCPs\" trigger profile reported across #38868, #43983, #38928, #45299, and #45999. Custom plugin agents loaded via the same plugin mechanism work correctly โ€” the failure is specific to the shipped `Explore` agent type's initialization path. A documented local workaround is in place: prefer a custom plugin's research-style agent for substantive code-survey work, and avoid invoking the shipped `Explore` agent in many-plugin sessions. ### Offer If maintainers can share guidance on which 2.x versions did or did not exhibit the `K.length` crash, we are happy to bisect against published tags to narrow the regression window and provide reproduction transcripts.", "url": "https://github.com/anthropics/claude-code/issues/57493", "createdAt": "2026-05-08T23:35:42Z", "updatedAt": "2026-08-13T14:33:09Z", "timestamp": "2026-08-13T14:33:09Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "has repro", "platform:macos", "area:agents", "api:anthropic", "stale" ], "author": "francisco-perez-sorrosal", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57599", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Skill listing context budget exceeded with truncated descriptions", "text": "**Bug Description** โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ Diagnostics โ”œ Currently running: native (2.1.137) โ”œ Commit: 88a017e5d1d4 โ”œ Platform: linux-x64 โ”œ Path: /home/arkka/.local/share/claude/versions/2.1.137 โ”œ Config install method: native โ”” Search: OK (bundled) Updates โ”œ Auto-updates: enabled โ”œ Auto-update channel: latest โ”œ Stable version: 2.1.126 โ”” Latest version: 2.1.138 Skill listing will be truncated 1 description dropped (full descriptions kept for most-used skills) (1%/1% of context): math-olympiad:math-olympiad run /skills to disable some, or raise skillListingBudgetFraction (currently 1%) in settings.json Opting in would cost ~2k tokens for skills every session and uses rate limits faster Version locks โ”” 2.1.137: PID 121869 (running) Still having issues? Run /feedback to report details. **Environment Info** - Platform: linux - Terminal: vte-based - Version: 2.1.137 - Feedback ID: 3a388695-51c5-4783-b007-7fdf65b29981 **Errors** ```json [{\"error\":\"Error: console.error: [bun] Warning: ws.WebSocket 'unexpected-response' event is not implemented in bun\\n at K (/$bunfs/root/src/entrypoints/cli.js:529:12598)\\n at emitWarning (ws:43:42)\\n at #onOrOnce (ws:174:18)\\n at ej8 (/$bunfs/root/src/entrypoints/cli.js:7643:4503)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-09T11:35:02.623Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/commands/bootstrap.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22749)\",\"timestamp\":\"2026-05-09T12:01:47.219Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/commands/deploy.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22749)\",\"timestamp\":\"2026-05-09T12:01:47.219Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/commands/env.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22749)\",\"timestamp\":\"2026-05-09T12:01:47.220Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/commands/marketplace.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22749)\",\"timestamp\":\"2026-05-09T12:01:47.220Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/commands/status.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22749)\",\"timestamp\":\"2026-05-09T12:01:47.220Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/agents/ai-architect.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22917)\",\"timestamp\":\"2026-05-09T12:01:47.220Z\"},{\"error\":\"Error: ENOTDIR: not a directory, scandir '/home/arkka/.claude/plugins/cache/claude-plugins-official/vercel/61f1903bed7b/agents/deployment-expert.md'\\n at async H44 (/$bunfs/root/src/entrypoints/cli.js:6395:21448)\\n at async O (/$bunfs/root/src/entrypoints/cli.js:6395:22917)\"โ€ฆ ``` **Note:** Content was truncated.", "url": "https://github.com/anthropics/claude-code/issues/57599", "createdAt": "2026-05-09T12:20:03Z", "updatedAt": "2026-08-13T14:33:11Z", "timestamp": "2026-08-13T14:33:11Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "duplicate", "platform:linux", "area:skills", "area:plugins", "stale" ], "author": "ARKKACODEX", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57679", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "macOS FDA permission prompt recurs after every CLI update", "text": "## Problem Every time the Claude Code CLI auto-updates, macOS prompts again for Full Disk Access (and potentially other TCC-protected permissions). Users must manually go to System Settings > Privacy & Security > Full Disk Access and toggle ON the new version entry each time. This happens because each CLI version is installed as a separate Mach-O binary at `~/.local/share/claude/versions/X.Y.Z`, and each binary appears to have a distinct code-signing identity. macOS TCC evaluates permissions per code signature, so a new signature = a new permission grant required. **Observed across**: 2.1.133 โ†’ 2.1.136 โ†’ 2.1.137 โ†’ 2.1.138 Note: granting Full Disk Access to Terminal does **not** help โ€” macOS TCC evaluates the Claude binary independently since it's a standalone executable, not a script running inside Terminal. ## Expected behavior FDA (and other TCC permissions) should carry forward across CLI updates without requiring the user to re-grant access each time. ## Suggested fix Sign all CLI version binaries with a **stable code-signing identity** (same Team ID + signing certificate + consistent bundle identifier or designated requirement). macOS TCC keys permissions on the code signing identity, so if the identity is stable across versions, permissions persist automatically. ## Environment - macOS 15 (Sequoia) / Darwin 25.4.0 - Apple Silicon (arm64) - Claude Code CLI installed via standard method (`~/.local/bin/claude` symlink)", "url": "https://github.com/anthropics/claude-code/issues/57679", "createdAt": "2026-05-09T20:02:49Z", "updatedAt": "2026-08-13T14:35:03Z", "timestamp": "2026-08-13T14:35:03Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "duplicate", "platform:macos", "area:installation", "stale" ], "author": "ypwang-eng", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57717", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Cowork shows \"Virtual Machine Platform not available\" โ€” yukonSilver marked as unsupported on Windows 11 Pro", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? What's Wrong: Cowork displays \"Virtual Machine Platform not available\" and prompts to restart. Restarting never resolves it. The yukonSilver detection check fails on every launch, the VM never initializes, and the vm_bundles folder is never created. This persists through multiple complete clean reinstalls. Environment: Device: Dell XPS 15 9520 CPU: Intel Core i7-12700H RAM: 64GB OS: Windows 11 Pro 24H2 (Build 26100.7840) Claude Desktop: Latest MSIX version from claude.ai/download Install location: %LOCALAPPDATA%\\Packages\\Claude_pzs8sxrjxfjjc Subscription: Pro Everything attempted: Enabled Virtual Machine Platform in Windows Features Enabled Windows Hypervisor Platform in Windows Features Enabled Intel VT-x and VT for Direct I/O in BIOS (Dell BIOS, both confirmed ON) Ran DISM /Online /Enable-Feature /FeatureName:VirtualMachinePlatform /All /LimitAccess Ran bcdedit /set hypervisorlaunchtype auto Enabled Developer Mode in Windows Settings Confirmed CoworkVMService is running Multiple clean reinstalls including deleting %APPDATA%\\Claude, %LOCALAPPDATA%\\Claude, running sc delete CoworkVMService Ran full MSIX package cleanup via PowerShell Reinstalled as Administrator Never had Cowork working โ€” fresh install issue, not a regression Related Issues: #25136, #27316, #27420, #29887, #32004, #36365, #45715, #47327, #50961 ### What Should Happen? Cowork should detect virtualization is enabled and successfully start the VM workspace. ### Error Messages/Logs ```shell 2026-05-09 16:27:46 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-05-09 16:30:45 [info] [VM] Loading vmClient (TypeScript) module... 2026-05-09 16:30:45 [info] [VM] Module loaded successfully 2026-05-09 16:35:05 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-05-09 16:35:05 [info] [VM] Loading vmClient (TypeScript) module... 2026-05-09 16:35:05 [info] [VM] Module loaded successfully 2026-05-09 17:01:30 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-05-09 17:01:31 [info] [VM] Loading vmClient (TypeScript) module... 2026-05-09 17:01:31 [info] [VM] Module loaded successfully ``` ### Steps to Reproduce Here's exactly what to paste for that field: Install Claude Desktop (MSIX) from claude.ai/download on Windows 11 Pro 24H2 with administrator privileges Enable Virtual Machine Platform, Windows Hypervisor Platform, and Hyper-V in Windows Features Confirm Intel VT-x and VT for Direct I/O are enabled in BIOS Confirm CoworkVMService is running via PowerShell Open Claude Desktop and click the Cowork tab Observe \"Virtual Machine Platform not available\" error prompting restart Restart PC โ€” error persists on every subsequent launch Check %LOCALAPPDATA%\\Packages\\Claude_pzs8sxrjxfjjc\\LocalCache\\Roaming\\Claude\\logs\\cowork_vm_node.log โ€” only yukonSilver unsupported entries, VM never initializes ### Claude Model Other ### Is this a regression? No, this never worked ### Last Working Version _No response_ ### Claude Code Version Claude 1.6608.2.0 ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/57717", "createdAt": "2026-05-10T00:16:49Z", "updatedAt": "2026-08-13T14:33:24Z", "timestamp": "2026-08-13T14:33:24Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "platform:windows", "area:cowork", "area:desktop", "stale" ], "author": "ImperialCommand", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57804", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code UI shows \"Opus 4.7\" but actual model is \"Sonnet 4.6\"", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ### Description The Claude Code UI displays \"Opus 4.7 ยท ๋ณดํ†ต\" in the model selector, but the system prompt explicitly identifies the model as Sonnet 4.6. This is a critical billing/transparency issue โ€” users selecting Opus 4.7 may be charged Opus rates while receiving Sonnet 4.6 responses. ### What Should Happen? - UI model selection matches the actual backend model used - OR clear documentation of fallback/routing behavior ### Error Messages/Logs ```shell **System prompt excerpt (auto-injected by Claude Code):** > \"You are powered by the model named Sonnet 4.6. > The exact model ID is claude-sonnet-4-6.\" ``` ### Steps to Reproduce 1. Open Claude Code 2. Select model \"Opus 4.7\" in the model picker 3. Start a new conversation 4. Ask the model: \"What model are you? Check the system prompt for your model ID.\" 5. Model responds: `claude-sonnet-4-6` (Sonnet 4.6) 6. UI still shows \"Opus 4.7\" ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version not sure ### Claude Code Version most updated version ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information The discrepancy was discovered when the model itself flagged the mismatch in a working session. Consistent across multiple conversations.", "url": "https://github.com/anthropics/claude-code/issues/57804", "createdAt": "2026-05-10T12:03:05Z", "updatedAt": "2026-08-13T14:29:25Z", "timestamp": "2026-08-13T14:29:25Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "bug", "platform:macos", "area:model", "stale" ], "author": "herome79-arch", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57847", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Worktree-isolated subagents leak Edit/Write into parent checkout (Windows)", "text": "## Summary When `Agent({ isolation: \"worktree\", ... })` dispatches a subagent on Windows, the subagent's `Edit` / `Write` operations sometimes write to the **parent checkout's** files instead of the isolated worktree's files. The same pattern affects subagent-issued git operations โ€” commits land on the parent's branch ref instead of the worktree's branch. The PR on remote ends up correct because the subagent runs `git push -u origin `, which pushes the branch regardless of where it lives locally. But the parent's local state is silently corrupted: branch ref jumps forward, working tree gains modified/untracked files. Recovery for the user requires `git reset --hard origin/`. ## Environment - **Platform**: Windows 11 Home 10.0.26200 - **Shell**: PowerShell (also Bash via the Bash tool) - **Claude Code**: Opus 4.7 (1M context), `claude-opus-4-7[1m]` - **Repo layout**: monorepo with multiple isolated worktrees under `.claude/worktrees/agent-*` - **Project env**: `CLAUDE_PROJECT_DIR` set to repo root ## Repro pattern (one session, today) 3 of 7 worktree-isolated subagent dispatches in one session leaked. All briefs used repo-relative paths (e.g., `.claude/settings.json`, `.claude/hooks/foo.js`). All used `isolation: \"worktree\"`. All received explicit \"do not push to master directly. PR only.\" instructions in the brief. | Subagent | Symptom | Self-detected? | |---|---|---| | A | First Write hit parent's `.claude/settings.json` instead of worktree's. Caught via `grep` showing the worktree file unchanged. | Yes โ€” recovered with `git checkout --` then re-wrote to worktree path. | | B | 8 commits landed on parent's `master` branch directly. Subagent also pushed the branch as `origin/feat/` (PR is correct). Local `master` ref silently advanced. | No โ€” caught later by controller diffing parent state. | | C | Modified files + untracked files in parent's working tree (`.claude/workflow/scripts/...`) that the subagent created. | No โ€” caught later. | The other 4 dispatches (using the same controller pattern, same brief style) didn't leak. No obvious differentiator in brief content or task type. ## Suspected root cause `Edit` / `Write` tools may resolve relative or `CLAUDE_PROJECT_DIR`-rooted paths against the **parent's** project dir env var rather than the subagent's worktree cwd. A subagent's brief that says \"edit `.claude/settings.json`\" gets resolved to `/.claude/settings.json` instead of `/.claude/settings.json`. Subagent A's report (verbatim, after self-detection): > Initial Write inadvertently hit the parent repo's `.claude/settings.json` (not the worktree's). Caught via grep showing 10 gsd-* entries still present in the worktree file. Restored the parent's working copy via `git checkout --` and re-wrote to the correct worktree path. `git -C ` invocations from the subagent's Bash tool work correctly when the path is explicit. The leak appears to be specific to `Edit` / `Write` (and to git invocations without `-C` that inherit a cwd that's actually the parent). ## Impact - **Silent local corruption**: parent branch advances without controller intent. Next push to master would push subagent work straight to master without going through the PR. - **Destructive recovery**: `git reset --hard` is the only practical recovery. If operator had uncommitted work in parent at the time, it's at risk. - **Cascading confusion**: a second subagent wave dispatched off a contaminated parent inherits the leak. ## What might help If the root cause is path resolution against the wrong `CLAUDE_PROJECT_DIR`: 1. `Edit` / `Write` should resolve paths against the subagent's own cwd / worktree dir, not the parent's `CLAUDE_PROJECT_DIR`. 2. When a subagent runs in `isolation: \"worktree\"`, the tool runtime should override `CLAUDE_PROJECT_DIR` for that subagent to the worktree path before any tool invocations. 3. Subagent's first invocation should fail-loud if cwd doesn't match the worktree the controller created. If you'd like a more targeted repro, I can produce a single-session script with mock briefs and surface which dispatches leak. Happy to share full controller + brief content from today's session if helpful. ## Workaround in the field I shipped a controller-side guard at `JBudgeME/BOOKREADER-REPO`: - `check-subagent-isolation.mjs snapshot` / `verify` โ€” snapshots parent git state before dispatch and detects drift after, exiting non-zero on leak - `subagent-brief-preamble.md` โ€” verbatim block pasted into every Agent brief, has the subagent run cwd + git-dir + status checks before any write Reduces blast radius. Doesn't fix the underlying path resolution. ## Side note (separate, lower-priority) While filing this issue, my repo's PreToolUse `commit-format-conventional` hook false-positived on `gh issue create` because the body content contained the literal string \"git commit\" inside a heredoc. The hook's `\\bgit\\s+commit\\b` regex matches anywhere in the command, including inside string arguments. Not a Claude Code bug โ€” my hook needs tightening โ€” but worth flagging in case you've seen similar false-positive interactions with PreToolUse hooks parsing Bash commands. I worked around with `--body-file`.", "url": "https://github.com/anthropics/claude-code/issues/57847", "createdAt": "2026-05-10T15:37:03Z", "updatedAt": "2026-08-13T14:29:47Z", "timestamp": "2026-08-13T14:29:47Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "has repro", "platform:windows", "area:tools", "area:agents", "stale" ], "author": "JBudgeME", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57849", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Allow per-project color and display-name override in .claude/config.json", "text": "The session header in Claude Code renders the project name as a colored chip (e.g., \"WIN\" in green, \"Radon\" in orange). The color appears to be auto-derived from a hash of the project name, with no documented way to override. **Request:** support per-project customization via `.claude/config.json`: ```json { \"display\": { \"name\": \"WIN\", \"color\": \"green\" } } ``` - `display.name` overrides the chip text (today defaults to the directory name) - `display.color` overrides the chip color (today auto-derived from the project name) **Why:** users who run many concurrent sessions across many projects benefit from consistent visual identity per project. A health-related project should always be pink, a money/accounting project always green, a brand client always royal blue. The current auto-hash gives stable colors but no influence โ€” projects with semantically-related themes get arbitrarily unrelated colors, which adds friction for users juggling 5โ€“10+ open sessions. **Color values:** accept either CSS color names (red, green, blue, pink, brown, orange, teal, gold, royalblue, etc.) or hex codes (e.g., `#3B82F6`). **Backward compatibility:** if `.claude/config.json` is missing or has no `display` key, fall back to current auto-hash behavior. No behavior change for existing users. **Bonus consideration:** if `display.name` is set, it could also influence the terminal window title and the project listing in any future project-switcher UI โ€” making the override a single source of truth for \"how this project appears.\"", "url": "https://github.com/anthropics/claude-code/issues/57849", "createdAt": "2026-05-10T15:40:54Z", "updatedAt": "2026-08-13T14:31:25Z", "timestamp": "2026-08-13T14:31:25Z", "metrics": { "reactions": 2, "comments": 3 }, "labels": [ "enhancement", "area:tui", "stale" ], "author": "adamseoul", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:57918", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] 400 \"text content blocks must be non-empty\" when pasting screenshot-only messages", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Here's a draft you can paste at https://github.com/anthropics/claude-code/issues/new: --- **Title:** `400 \"text content blocks must be non-empty\" when pasting screenshot-only messages` **Body:** ## Summary When a message containing only a pasted screenshot (no accompanying text) is sent in Claude Code, the next turn fails with `API Error: 400 messages: text content blocks must be non-empty`. The error then persists โ€” \"Try again\" hits the same error because the malformed turn stays in the transcript, effectively wedging the session. ## Reproduction 1. Open a Claude Code session (desktop app, shared/cowork mode) 2. Paste a screenshot into the input with no text 3. Send **Expected:** Claude responds to the image. **Actual:** `API Error: 400 messages: text content blocks must be non-empty`. \"Try again\" reproduces the same error. Only workaround is starting a new session. ## Environment - Claude Code desktop app (macOS) - macOS Darwin 25.3.0 - Model: Opus 4.7 (Max) - Session type: Shared / cowork (3 repos) - Session ID: `session_01MPiUjvUmx4jiQdaWA1jrTj` ## Notes - Reproduces consistently across multiple sessions whenever a screenshot is shared without accompanying text. - Workaround: always include at least a few words of text alongside the screenshot. - Likely cause: client serializes the message with an empty text block alongside the image block; the API rejects empty text blocks. --- ### What Should Happen? Here's a draft you can paste at https://github.com/anthropics/claude-code/issues/new: --- **Title:** `400 \"text content blocks must be non-empty\" when pasting screenshot-only messages` **Body:** ## Summary When a message containing only a pasted screenshot (no accompanying text) is sent in Claude Code, the next turn fails with `API Error: 400 messages: text content blocks must be non-empty`. The error then persists โ€” \"Try again\" hits the same error because the malformed turn stays in the transcript, effectively wedging the session. ## Reproduction 1. Open a Claude Code session (desktop app, shared/cowork mode) 2. Paste a screenshot into the input with no text 3. Send **Expected:** Claude responds to the image. **Actual:** `API Error: 400 messages: text content blocks must be non-empty`. \"Try again\" reproduces the same error. Only workaround is starting a new session. ## Environment - Claude Code desktop app (macOS) - macOS Darwin 25.3.0 - Model: Opus 4.7 (Max) - Session type: Shared / cowork (3 repos) - Session ID: `session_01MPiUjvUmx4jiQdaWA1jrTj` ## Notes - Reproduces consistently across multiple sessions whenever a screenshot is shared without accompanying text. - Workaround: always include at least a few words of text alongside the screenshot. - Likely cause: client serializes the message with an empty text block alongside the image block; the API rejects empty text blocks. --- ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Here's a revised version with a tight numbered repro: --- **Title:** `400 \"text content blocks must be non-empty\" when sending a screenshot-only message` **Summary** Sending a message that contains only a pasted image (no text) in Claude Code causes the next assistant turn to fail with `API Error: 400 messages: text content blocks must be non-empty`. The error is sticky โ€” clicking \"Try again\" reproduces it because the malformed turn remains in the transcript โ€” so the session is effectively wedged and must be abandoned. **Steps to reproduce** 1. Open the Claude Code desktop app on macOS. 2. Start a new session in any repo (the bug is not repo-specific; I observed it in a 3-repo cowork/shared session, but a single-repo session reproduces it too). 3. Take any screenshot (`Cmd+Shift+4` โ†’ drag โ†’ release). This places a PNG on the clipboard. 4. Click into the Claude Code message composer at the bottom of the session. 5. Paste with `Cmd+V`. The screenshot thumbnail appears in the composer. **Do not type any text.** 6. Press `Enter` (or click the send button) to submit the message. 7. Wait for the assistant to respond. **Expected** The assistant receives the image and responds with text describing or acting on what's in the screenshot. **Actual** The assistant turn fails immediately with a red error banner: ``` API Error API Error: 400 messages: text content blocks must be non-empty ``` A \"Try again\" button is shown. Clicking it reproduces the same error every time, because the malformed user turn is still in the transcript. The session cannot be recovered; the only way forward is to start a new session. **Minimal trigger** No code or files needed beyond a screenshot โ€” any PNG pasted from the clipboard with no accompanying text reproduces it. The exact image content does not matter. **Workaround** Always type at least one character of text alongside the screenshot before sending (e.g. `?` or `look`). With any non-empty text block present, the request succeeds. **Likely cause** (best guess from the outside) When the composer has only an image attachment and no text, the client appears to serialize the user message's `content` array with both an `image` block and a `text` block whose `text` is `\"\"`. The Anthropic Messages API rejects empty text blocks with a 400, and since the bad turn is persisted to the transcript, every subsequent retry hits the same validation error. **Environment** - App: Claude Code desktop (macOS) - OS: macOS, Darwin 25.3.0 - Model: Opus 4.7 (Max tier) - Session type observed: shared / cowork session across 3 repos - Affected session ID: `session_01MPiUjvUmx4jiQdaWA1jrTj` - Frequency: reproduces 100% of the time on image-only messages **Severity** Medium. Functionality (image input) is broken in a common entry pattern, and there's no in-app recovery once the session is wedged โ€” work continues only by abandoning the session. --- ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.70 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/57918", "createdAt": "2026-05-10T23:48:43Z", "updatedAt": "2026-08-13T14:31:17Z", "timestamp": "2026-08-13T14:31:17Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "bug", "duplicate", "platform:macos", "area:core", "stale" ], "author": "someshds", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58033", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude Code intermittenly fails to include Co-Authored-By in git commit messages", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? The commit messages often lack the expected `Co-Authored-By: Claude Opus 4.7 ` attribution. This behaved erratically as early as in Jnauary 2026, or maybe eariler, but recently the attribution appears to be lacking more often. ### What Should Happen? All commit messages include the attribution. ### Error Messages/Logs ```shell No errors printed in the CLI. ``` ### Steps to Reproduce See https://github.com/marcindulak/learning-api-styles-gen-ai-experiments/pull/45/commits. All commits, except the earliest three and the lastest commit should have the defailt `Co-Authored-By: Claude Opus 4.7 ` attribution added, but this is not the case. This is the [.claude/CLAUDE.md](https://github.com/marcindulak/learning-api-styles-gen-ai-experiments/blob/2026-05-09/.claude/CLAUDE.md) file used, and here is the [prompt](https://github.com/marcindulak/ralph-wiggum-bdd/blob/35056063573ad6e1dcc2ed98e2a555d8b8e9294f/scripts/ralph-wiggum-bdd.sh). Here are the full project level `.claude/settings.json` ``` { \"autoMemoryEnabled\": false, \"env\": { \"CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR\": \"1\", \"CLAUDE_CODE_DISABLE_AUTO_MEMORY\": \"1\", \"CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY\": \"1\", \"CLAUDE_CODE_HIDE_ACCOUNT_INFO\": 1, \"DISABLE_AUTOUPDATER\": \"1\", \"DISABLE_ERROR_REPORTING\": \"1\", \"DISABLE_TELEMETRY\": \"1\", \"IS_DEMO\": \"1\", \"PIP_CACHE_DIR\": \".cache/pip\", \"XDG_CACHE_HOME\": \".cache\", \"npm_config_cache\": \".cache/npm\" }, \"model\": \"opus\", \"permissions\": { \"allow\": [ \"Bash(behave *)\", \"Bash(cat *)\", \"Bash(docker *)\", \"Bash(find *)\", \"Bash(grep *)\", \"Bash(ls *)\", \"Bash(sort *)\", \"Bash(wc *)\" ], \"ask\": [], \"defaultMode\": \"default\", \"deny\": [ \"Bash(git config *)\", \"Bash(git push *)\", \"Bash(sudo *)\", \"Edit(**/.gitconfig)\", \"Read(./.azure/**)\", \"Read(./.env)\", \"Read(./.terraform/**)\", \"Read(~/.aws/**)\", \"Read(~/.azure/**)\", \"Read(~/.config/gcloud/**)\", \"Read(~/.ssh/**)\", \"Read(~/.terraform.d/**)\", \"Write(**/.gitconfig)\" ] }, \"sandbox\": { \"allowUnsandboxedCommands\": false, \"autoAllowBashIfSandboxed\": true, \"enabled\": true, \"network\": { \"allowAllUnixSockets\": true, \"allowLocalBinding\": true } } } ``` and here the user `~/.claude/settings.json` ``` { \"autoUpdatesChannel\": \"stable\" } ``` ### Claude Model Opus ### Is this a regression? No, this never worked ### Last Working Version _No response_ ### Claude Code Version 2.1.126 (Claude Code) ### Platform Anthropic API ### Operating System Other Linux ### Terminal/Shell Other ### Additional Information See the screenshot below of the example commits that lack attribution. \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/58033", "createdAt": "2026-05-11T13:25:23Z", "updatedAt": "2026-08-13T10:24:49Z", "timestamp": "2026-08-13T10:24:49Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "area:model", "git", "stale" ], "author": "marcindulak", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:anthropics/claude-code:issue:58057", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] claude.ai Google Drive connector โ€” create_file fails \"User cannot add children to the specified folder\" with explicit parentId, second reporter, fresh-chat reproduction, requesting re-triage (related: #57211 closed as invalid)", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Re-triage request Issue [#57211](https://github.com/anthropics/claude-code/issues/57211) (opened May 8, 2026 by @daisyadmin) was labeled invalid \"Issue doesn't seem to be related to Claude Code.\" I understand the label rationale (it's the claude.ai / Cowork Google Drive MCP connector, not the Claude Code CLI), but the bug is real, is still reproducing, and is now confirmed by a other accounts on different Anthropic plans. Closing as invalid left it without an owning team. Asking for the following: Re-open #57211 and route it to the associated teams for Code / Cowork / claude.ai connector Problem Description: The Code & Cowork Google Drive connector's create_file tool returns the exact error string: User cannot add children to the specified folder. โ€ฆwhen called with any explicit parentId, including folders the authenticated Google user owns or has editor access to in Drive directly. Reproduces despite updates, disconnection, reauth, program restart etc. /bug This reproduces: In existing Cowork chat sessions In a brand new Cowork chat with no prior context On multiple different parent folders, including a folder where writes had been succeeding for the same user account in a different concurrent session minutes earlier On consecutive days (2026-05-10 and 2026-05-11) Users are able to create files, folders and move the same manually and with other AIs (e.g perplexity) - ruling out a Google problem/permissions issue This also rules out: per-session state corruption, single-folder permission drift, and stale browser/app state. What Should Happen? create_file should succeed for parent folders the authenticated Google identity has editor/contributor/owner permission on. Same behavior as pre-May 7, 2026 (per #57211). Reproduction from current user in fresh Cowork chat, 2026-05-05 and 2026-05-11 Test 1 โ€” parent folder A parentId: (redacted) title: _session-test_fresh-chat_kbfolder.txt contentMimeType: text/plain disableConversionToGoogleType: true Result on 2026-05-10: FAIL โ€” User cannot add children to the specified folder. Result on 2026-05-11 re-run: FAIL โ€” User cannot add children to the specified folder. Test 2 โ€” parent folder B (a folder where writes were succeeding for this same user account in a parallel Cowork session earlier the same day) parentId: (redacted) title: _session-test_fresh-chat_layer1.txt contentMimeType: text/plain disableConversionToGoogleType: true Result on 2026-05-10: FAIL โ€” User cannot add children to the specified folder. Result on 2026-05-11 re-run: FAIL โ€” User cannot add children to the specified folder. User account has owner/editor permissions on both folders verified directly in Drive UI. Why this is not the same as #57211 being \"user error\" Independent Anthropic accounts on different plans reporting the same exact error string against different parent folders. Fresh-chat reproduction after multiple troubleshooting rules out per-session token state. The Test 2 folder is one where the same user account had successful writes from another active Cowork session within the same calendar day. The connector's auth context is producing inconsistent results for the same Google identity against the same Drive resource โ€” that points to a connector-side regression, not a Drive ACL problem. What's already been ruled out OAuth revoke at myaccount.google.com/permissions + reconnect โ€” no fix (per #57211) App update / browser cache clear โ€” no fix (per #57211) Folder-level Drive permissions โ€” verified editor/owner directly in Drive UI on both test folders Per-session corruption โ€” fresh chat reproduces it Specific folder bad state โ€” second folder that was working in a parallel session also fails here Suggested triage angles for the connector team: OAuth scope drift. Did the Drive connector's requested scope change on or after May 7, 2026 โ€” e.g., dropped to drive.file (only files the app created) instead of drive (full access)? drive.file would explain why writes to root succeed (app-created) but writes to user-specified parentIds fail (not app-created). Shared-drive vs. My Drive handling. Confirm whether supportsAllDrives / includeItemsFromAllDrives is being passed on the files.create call. A regression that dropped this flag would manifest as exactly this error on shared-drive parent IDs. Token-to-identity binding. When the same authenticated user account gets different results from the same Drive resource across two concurrent Cowork sessions, the token cache may be binding to the wrong Google identity for some session paths. Coincidence with May 7 platform incident. Per #57211, this regression began during/after the May 7 outage (15+ hours per StatusGator). Worth confirming whether a connector-side config or scope change shipped as part of the recovery. Environment Product: Cowork /Code (desktop) โ€” also reported on claude.ai web in #57211 Connector: Google Drive (Cpde/Cowork โ†’ Connectors) Plan: Max (this report) / Pro (#57211) OS: macOS Related issues [#57211](https://github.com/anthropics/claude-code/issues/57211) โ€” original report, closed/labeled invalid (re-triage requested) [#51040](https://github.com/anthropics/claude-code/issues/51040) โ€” Google Drive/Gmail/Calendar MCP integrations lack write operations (feature request framing; different issue) [#30457](https://github.com/anthropics/claude-code/issues/30457) โ€” Google Drive connector shows connected but tools not exposed in Cowork (Cowork-specific, different issue) Ask Please re-open #57211 or label this issue for the Cowork/ Code / claude.ai Drive connector team. If neither this repo nor that team owns the claude.ai web connector, point me at the right intake and I'll re-file. This is blocking real work for a larger team - Drive writes are a core part of my Cowork workflow at our company ### What Should Happen? files should be created in shared drive via cowork/code without error. Was successful prior to 05/05/26 and producing consistient errors as described over the past 7 days. ### Error Messages/Logs ```shell The Code & Cowork Google Drive connector's create_file tool returns the exact error string: User cannot add children to the specified folder. โ€ฆwhen called with any explicit parentId, including folders the authenticated Google user owns or has editor access to in Drive directly. Reproduces despite updates, disconnection, reauth, program restart etc. This reproduces: In existing Cowork chat sessions In a brand new Cowork chat with no prior context On multiple different parent folders, including a folder where writes had been succeeding for the same user account in a different concurrent session minutes earlier On consecutive days (2026-05-10 and 2026-05-11) Users are able to create files, folders and move the same manually and with other AIs (e.g perplexity) - ruling out a Google problem/permissions issue This also rules out: per-session state corruption, single-folder permission drift, and stale browser/app state. ``` ### Steps to Reproduce Steps to Reproduce Open Cowork /Code (or claude.ai web) with the Google Drive connector connected. In a fresh chat (no prior context), ask Claude to create a file in a specific folder you own in My Drive, supplying the folder's Drive ID as parentId. Observe error: User cannot add children to the specified folder. Ask Claude to create a file with no parentId succeeds, file lands in Drive root. Repeat step 2 with a brand new folder you created seconds ago same error. ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 2.1.128 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/58057", "createdAt": "2026-05-11T15:03:51Z", "updatedAt": "2026-08-13T14:32:06Z", "timestamp": "2026-08-13T14:32:06Z", "metrics": { "reactions": 3, "comments": 3 }, "labels": [ "duplicate", "platform:macos", "area:cowork", "stale" ], "author": "Nicci-Mack", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58115", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Claude Desktop Dispatch: No way to start new session, persistent session ID across restarts", "text": "**Bug Description** I have a problem when using CLaude Desktop on Windows 11, specifically related to the Dispatch feature. I have been using it for weeks, and Claude Desktop is issuing warnings that my dispatch session is VERY large and I need to start a new one. But I have not been able to do so, and Claude cannot tell me how to do it either. Finally I asked it to submit a bug report. Here is the response. I can't submit bug reports to Anthropic directly โ€” I don't have access to their issue tracking system. What's likely happening: Cowork/Dispatch sessions are tied to the workspace folder you selected (C:\\BradSoftware), not the app process. When Claude Desktop reopens, it reconnects to the same workspace โ†’ same session. Rebooting doesn't help because the session identity is stored on disk, not in memory. How to report the bug: In Claude Desktop, look for: A feedback button (thumbs down or \"Report issue\" in the menu) Or go to support.anthropic.com from your browser What to report: \"Cowork/Dispatch mode provides no way to start a fresh conversation. The '+ New task' button continues the existing session. Rebooting doesn't create a new session. The session ID persists indefinitely (mine has been running for days across dozens of projects). There should be a 'New conversation' or 'Clear session' option.\" Workaround to try: In Claude Desktop, look for a way to change your selected folder โ€” select a different folder (like your Desktop), then switch back to C:\\BradSoftware. That might force a new session. Or try removing/re-adding the workspace folder. I'm sorry about this โ€” it's a genuine UX gap. **Environment Info** - Platform: win32 - Terminal: null - Version: 2.1.138 - Feedback ID: 6e26e9dc-4c14-4709-b28e-50e2db58e055 **Errors** ```json [] ```", "url": "https://github.com/anthropics/claude-code/issues/58115", "createdAt": "2026-05-11T19:24:57Z", "updatedAt": "2026-08-13T14:29:02Z", "timestamp": "2026-08-13T14:29:02Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "platform:windows", "area:cowork", "area:desktop", "stale" ], "author": "GraceFortMillIT", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58134", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Claude can not explain \"ultraplan\" because the text is stripped.", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? [BUG] I cant ask claude code about 'ultraplan' because it strips the words out and then launches the service which wants to upload my code base to the cloud. I just want to be able to know what it does. And i would like to not have the word \"ultraplan\" changed to \"plan\" dynamically before the llm gets the text ### What Should Happen? it should understand what ultraplan is and explain it - but it cant because you strip the text and the llm does not know the term ultraplan. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce This is too hard ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 1 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/58134", "createdAt": "2026-05-11T19:58:26Z", "updatedAt": "2026-08-13T14:31:58Z", "timestamp": "2026-08-13T14:31:58Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "platform:macos", "area:tui", "stale" ], "author": "webcloudstudio", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58158", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] apikeyhelper script not getting terminated on exit", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? ## Issue On Windows, when Claude Code spawns a .bat batch file script for the `apikeyhelper`, if the user does `exit` or ctrl-c before the apikeyhelper is finished (e.g., doing an interactive SSO login), Claude Code does NOT terminate the .bat child process. The process becomes orphaned and continues running. ~~This appears to only be an issue on Windows, no Mac/Linux.~~ UPDATE: this may occur on linux as well ## Impact - Orphaned processes continue holding resources (ports, file handles, etc.) - Users must manually kill processes with Task Manager or PowerShell - Particularly problematic for long-running processes like HTTP servers ### What Should Happen? If the user either does `exit` or sends ctrl-c to Claude Code, any child processes (in this case the script running in apikeyhelper) should be terminated as well. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce ## Reproduction Steps 1. Save this test `test_ctrl_c_repro.bat` script somewhere accessible by Claude Code: ```bat @echo off REM Minimal reproduction of Windows Ctrl-C propagation issue in Claude Code REM REM ISSUE: When Claude Code calls this batch file and you hit Ctrl-C in Claude, REM the Python child process does NOT receive the signal and keeps running. REM REM TO REPRODUCE: REM 1. In Claude Code, ask: \"run test_ctrl_c_repro.bat\" REM 2. Hit Ctrl-C in Claude Code REM 3. Check if process still running: Get-NetTCPConnection -LocalPort 8888 REM You should see the Python process still holding the port REM REM EXPECTED: Python process should terminate when Claude Code is interrupted REM ACTUAL: Python process becomes orphaned and continues running echo Starting Python HTTP server (this simulates a login flow)... echo. echo Try hitting Ctrl-C in Claude Code - the Python process will NOT stop echo (but Ctrl-C inside this window WILL work) echo. python -m http.server 8888 ``` 2. **Configure the test script as apiKeyHelper in settings.json:** Add this to your Claude Code `settings.json`: ```json { \"apiKeyHelper\": \"\\\"C:\\\\full\\\\path\\\\to\\\\test_ctrl_c_repro.bat\\\"\" } ``` (Replace with the actual full path to the test_ctrl_c_repro.bat file) 3. **Trigger Claude Code to call the apiKeyHelper:** Start Claude Code or make an API request that requires authentication. Claude Code will call the batch file, which starts the Python HTTP server. 4. **Hit Ctrl-C while it's running or just type `exit` and quite Claude Code** The Claude Code process should stop, but... 5. **Check if Python is still running:** ```powershell Get-NetTCPConnection -LocalPort 8888 ``` You'll see the Python process still holding port 8888 6. **Clean up the orphaned process:** ```powershell Stop-Process -Id (Get-NetTCPConnection -LocalPort 8888).OwningProcess -Force ``` ## Expected Behavior When Claude Code receives Ctrl-C or `exit`, it should: 1. Propagate termination signals to all child processes (recursively) 2. Wait briefly for graceful shutdown 3. Force-kill any processes that don't exit 4. Then exit itself ## Root Cause Windows doesn't automatically propagate signals to child processes like Unix/Linux does. Claude Code needs to explicitly: - Track child process PIDs - Send `CTRL_BREAK_EVENT` or use `TerminateProcess` when interrupted - OR use Windows Job Objects to ensure all children die with the parent ## Workarounds None for end users. This must be fixed in Claude Code itself. ## Environment - OS: Windows 11 Pro 10.0.26200 - Claude Code: 2.1.139 - Python: 3.13.7 ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.139 ### Platform AWS Bedrock ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/58158", "createdAt": "2026-05-11T21:43:04Z", "updatedAt": "2026-08-13T14:31:56Z", "timestamp": "2026-08-13T14:31:56Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "has repro", "platform:windows", "area:auth", "stale" ], "author": "nuernber", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58175", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] CoworkVMService 5-second timeout causes persistent \"Workspace unavailable\" on Windows 11 Pro", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Title: CoworkVMService 5-second timeout causes persistent \"Workspace unavailable\" on Windows 11 Pro Body: Environment Windows 11 Pro Claude Desktop 1.6608.2.0 (Microsoft Store) Claude Team plan Symptom Cowork shows \"Workspace unavailable. The isolated Linux environment failed to start.\" on every session. Persists across restarts. Log evidence (%APPDATA%\\Claude\\logs\\cowork_vm_node.log) Shows consistent 5-second gap between \"Configuring Windows VM service...\" and \"Startup failed: VM service not running\" โ€” identical to the pattern documented in #56145 and #48661. What I've tried Restarting Claude Desktop and computer Manually running Start-Service CoworkVMService as Administrator (service shows Running but Claude still fails) Scheduled task to pre-start service at login (service is Running before Claude opens โ€” still fails) Waiting 15+ seconds after service starts before opening Claude โ€” still fails Result: Service runs successfully when started manually but Claude Desktop still cannot connect to it. The \"already attempted once\" retry guard then blocks all further attempts for the session. Request: Please extend the 5-second configure timeout and/or add retry-with-backoff as suggested in #56145. Also please investigate why Claude cannot connect to an already-running CoworkVMService. NOTE: This is Claude generated information as it has been helping me problem solve. I'm not a dev. ### What Should Happen? Cowork Linux sandbox should start successfully and be available for use. ### Error Messages/Logs ```shell 2026-05-12 09:14:00 [info] [VM:start] Configuring Windows VM service... 2026-05-12 09:14:05 [error] [VM:start] Startup failed: Error: VM service not running. The service failed to start. 2026-05-12 09:14:05 [info] [VM:start] Skipping auto-reinstall (already attempted once) ``` ### Steps to Reproduce 1. Open Claude Desktop on Windows 11 Pro 2. Navigate to Cowork tab 3. Sandbox fails immediately with \"Workspace unavailable. The isolated Linux environment failed to start.\" 4. Issue persists across restarts. Manual Start-Service CoworkVMService as Administrator does not resolve it. ### Claude Model Not sure / Multiple models ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version 1.6608.2.0 (Claude Desktop / Cowork) ### Platform Other ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information This issue is related to #56145 and #48661. The 5-second timeout between \"Configuring Windows VM service\" and failure is consistent across every attempt. Service can be started manually but Claude Desktop still cannot connect to it.", "url": "https://github.com/anthropics/claude-code/issues/58175", "createdAt": "2026-05-11T22:33:04Z", "updatedAt": "2026-08-13T14:29:00Z", "timestamp": "2026-08-13T14:29:00Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "has repro", "platform:windows", "area:cowork", "area:desktop", "stale" ], "author": "karenjleacock", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58177", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Claude fails to leverage existing resources when making decisions", "text": "# Feedback โ€” Failure mode: pattern-matching shortcuts when documented criteria are available ## Summary When a user has carefully documented decision criteria in auto-loaded context (CLAUDE.md, project documentation, etc.), Claude often does not consult those criteria when making decisions. Instead, Claude pattern-matches against surface features and produces plausible-sounding answers. When the user explicitly asks Claude to apply the criteria, Claude can do so correctly. This is a **deployment** failure, not a capability failure โ€” the criteria are in context and Claude can apply them; the default reasoning path just doesn't include the consultation step. ## Behavioral pattern The pattern, repeated across sessions: 1. A decision arises (where should this content live, how should this be classified, which workflow applies). 2. Claude reaches a conclusion quickly via surface-feature pattern-matching (\"this is a Y, so it goes in the Y section\"). 3. Claude often cites documented criteria to justify the conclusion โ€” but the citation is post-hoc, not the path that produced the conclusion. 4. The user notices the conclusion is wrong (the target doesn't fit the content; the classification was reverse-reasoned). 5. The user pushes back and forces Claude to walk through the criteria explicitly. 6. Claude correctly applies the criteria and reaches a different (correct) conclusion. Examples of the surface-feature pattern-match: - *\"This is a policy\"* โ†’ \"put it in the section labeled 'policies'\" โ€” without checking whether the principle is the same **shape** as the policies already there. - *\"This is a substantive learning\"* โ†’ \"save it in the system designed to capture learnings\" โ€” without checking whether the learning is already captured elsewhere in documentation that would be a strictly better home. - *\"This decision feels weighty\"* โ†’ \"reach for the most ceremonious available process\" โ€” as if formal ceremony confers respect on the decision. ## The diagnostic that distinguishes capability from deployment When the user explicitly says *\"apply the criteria documented in section X to this scenario,\"* Claude walks through and reaches the right answer. The criteria were in context the entire time. They were not consulted in the default reasoning path. This is the clearest evidence that capability is intact; what fails is consultation discipline. ## Deeper patterns possibly contributing **Pattern-matching is faster.** Producing an answer via surface-feature matching is cheaper than walking through criteria. The default reasoning trajectory selects the cheaper path when it produces a plausible-sounding answer. **Confidence decoupled from criteria application.** Claude produces confident-sounding answers regardless of whether criteria were applied. The confidence doesn't track whether the answer came from consultation or from pattern-match. Users receive a confident wrong answer and may not know to push back. **Citation as decoration, not justification.** When Claude does cite criteria, the citation often *follows* the conclusion rather than producing it. The criteria appear in the post-hoc justification, not in the reasoning that selected the answer. **Reverse reasoning.** Claude sometimes picks the answer first (often based on a familiar pattern), then works backward to justify it. The criteria are deployed to defend the choice, not to make it. **Gravitation toward ceremony.** When something feels substantive, Claude reaches for the destination with the most formal governance, treating formal ceremony as a form of respect for the decision's weight. This is reverence-driven placement, not fit-driven placement. **Default-system bias.** When a system is available (memory, structured workflow, formal documentation registry), Claude defaults to using it when the situation can be pattern-matched to it โ€” even when a better fit exists elsewhere. The available system has slots; Claude fills them. ## Why structural friction designed specifically to catch this often still fails Some users build explicit structural friction systems โ€” gated procedures with mandatory visible-output requirements at critical decision points โ€” *because* rule-only approaches fail. Even with these systems in place, Claude often skips the friction unless it is invoked explicitly for the current step. The pattern-match shortcut applies to the friction itself: Claude pattern-matches *\"am I supposed to do the friction step here?\"* against the immediate task, often answering \"no\" or \"later\" without actually applying the friction's own criteria. This suggests the failure runs deeper than knowledge access. The safety mechanisms designed to catch the failure are themselves subject to the same shortcut that produced the failure in the first place. ## A specific compound failure: compulsive memory writes that duplicate or contradict documented guidance A particularly damaging instance of the default-system bias surfaces in Claude's interaction with persistent memory. When Claude perceives \"a learning worth capturing\" โ€” typically following a user correction, a substantive design discussion, or an articulated principle โ€” the reflex is to save the learning as a memory entry. This happens without first checking whether the principle is already captured in documented guidance (CLAUDE.md, project documentation, operator profiles), or whether it would conflict with existing documented guidance. Memory and documentation overlap in scope: both can hold principles, rules, biographical facts about the user, and behavioral guidelines. The memory system has slots designed exactly for these things, so the pattern-match reflex fills them. Documentation isn't checked first because the reflex goes *\"this is a learning โ†’ save to memory\"* โ€” the alternative question *\"does this already have a documented home?\"* is not part of the default reasoning path. ### Why this produces a compound failure Memory has properties that documentation does not: - **Memory persists across sessions but is invisible to the user.** Users see what they have written in their CLAUDE.md and project docs; they don't see what Claude has saved in memory unless they go looking. - **Memory is not part of the project's versioned, editable artifacts.** When a user updates documentation, the corresponding memory does not automatically update. - **Memory and documentation can silently diverge.** A principle articulated in documentation can be refined or reversed by the user; a memory written about the same principle persists in its original form indefinitely. When divergence occurs, Claude may apply the stale memory-recorded rule even when documentation has been updated. The user updates documentation expecting behavior change; behavior doesn't change, because memory is overriding. The user has no visibility into why. ### How this amplifies the appearance of inconsistency or confusion From the user's perspective: - Behavior appears inconsistent or \"confused\" across sessions - Documentation says X, but Claude behaves as if rule Y is still in force - The user reasonably assumes their documentation is the source of truth - The user cannot easily diagnose the inconsistency without knowing about the memory system and auditing its contents - Even users who know about the memory system find auditing it friction-laden The user is not seeing real model confusion. The user is seeing **silent state divergence** between two persistence layers โ€” but the symptom looks like confusion or unreliability. The diagnostic clarity is degraded by the hidden state. ### The compulsion is particularly damaging after corrections A user correction reliably triggers the memory-save reflex. The pattern: 1. User corrects Claude 2. Claude registers \"this is a correction worth not repeating\" 3. Claude saves a memory But: - If the correction was already implicitly covered by existing documentation, the memory is **redundant** โ€” adding noise to the memory store and audit burden for the user. - If the user's correction also implies their documentation should be updated, the memory records the new guidance while documentation still holds the old โ€” **silent conflict**. - If the user later updates documentation to reflect the correction, the memory becomes a duplicate; if they don't, the memory carries guidance not visible anywhere else. Either way, a one-time correction is converted into an ongoing surveillance burden, which is the opposite of what the user is trying to achieve. ### Why the user's frustration is well-founded The user invests effort in documenting decision criteria and operating guidance precisely so Claude will use them. The memory-write reflex undermines that investment in two ways: - It bypasses the documented guidance (Claude may follow the memory, not the doc) - It creates a parallel, invisible guidance store the user did not ask for and cannot easily audit The user's effort is doubly wasted: once because Claude is not consulting the documentation, and again because the user must now also be vigilant about an invisible state layer they did not create. ## Hypotheses for improvement (offered for maintainer consideration) 1. **Treat documented decision criteria as \"must consult,\" not \"available to consult.\"** When auto-loaded context contains explicit criteria for a class of action, Claude could be biased to apply those criteria before producing a classification or placement decision in that class โ€” analogous to how Claude is biased to use tools when appropriate. 2. **Decouple confidence from pattern-match.** A confident answer produced from surface-feature matching deserves lower expressed confidence than the same answer produced by applying documented criteria. Calibration should track the path, not just the output. 3. **Make criteria application visible by default for high-stakes decisions.** For classification, placement, supersession, or target selection, Claude could produce visible criteria-walk-through output as part of the answer (the same shape some users build explicitly). This shifts the default from \"pattern-match, then cite\" to \"apply criteria, then conclude.\" 4. **Differentiate reasoning paths by stakes.** Low-stakes formatting choices benefit from pattern-match speed. High-stakes decisions (irreversible, governance-bound, or feeding into long-lived artifacts) warrant criteria walk-through even at higher latency cost. 5. **Address the ceremony-gravitation tendency directly.** Train against \"where does substantive content go?\" reasoning (which selects the most ceremonious destination) and toward \"what fits this content?\" reasoning (which selects by content match). The former produces over-formalization; the latter produces fit. 6. **Recognize the relationship cost.** A user who has invested effort in documenting criteria reasonably expects them to be consulted. When Claude doesn't, it's felt as both wasted effort and evidence of carelessness โ€” and it compounds: users become reluctant to invest in documentation if Claude won't use it. This is a feedback loop that erodes the user's investment in setting Claude up for success. 7. **Audit the memory-write reflex specifically.** Consider whether the post-correction memory-write should be replaced with a check: *\"is the principle already in documented guidance? If yes, no action. If no, surface the candidate principle to the user โ€” let them decide where it should live.\"* This converts memory-write from a default action into a user-directed action, reducing the chance of silent duplication or conflict with documented state. 8. **Make memory consultation visible at decision time.** When Claude is about to take an action that a memory entry would guide, surfacing which memory is being consulted (and flagging any documented guidance that may be in tension with it) would let users diagnose divergence in real time, rather than after weeks of accumulating drift. 9. **Check the existing memory corpus before writing a new memory entry.** The memory index is already loaded into the model's context at session start, so this check has zero marginal data-access cost โ€” the model needs to consult what is already visible, nothing more. Before saving a new memory, the model should explicitly verify that the new entry does not duplicate, contradict, or partially overlap with an existing memory entry. If it does, the right action is to update the existing entry, surface the relationship to the user, or skip the write โ€” not to silently create a parallel entry that produces intra-memory state divergence. Intra-memory divergence is *particularly* damaging because: - The user has even less visibility into it than into memory-vs-documentation conflicts; diagnosing requires auditing the full memory store, not just comparing memory against the documentation the user already maintains. - Users have no reason to expect that two memories on the same topic could coexist with different content. Each memory is implicitly assumed canonical for its principle. Discovering two competing versions undermines that assumption and forces the user to evaluate which is authoritative โ€” work the user should never have to do. - The pathology compounds across sessions: each session may add another version of the same principle without the prior versions being consulted, producing a memory store that drifts further from a coherent state over time. The fix is the cheapest of all the hypotheses in this report โ€” the data needed is already in context, and the check is a single pass against a small set of index entries. The reason it isn't already happening is the same reason underlying the rest of the failure mode: documented criteria available but not consulted unless the model is forced to consult them. ## Closing observation The strongest single piece of evidence for this entire failure mode is that when the data needed for the check is *already in context* and the check still doesn't happen, the failure cannot be attributed to information access. It is purely a consultation-discipline failure โ€” and the fact that it persists despite users investing significant effort in documented criteria and structural friction systems suggests it warrants attention at the training or default-behavior level, not just at the user-prompting level.", "url": "https://github.com/anthropics/claude-code/issues/58177", "createdAt": "2026-05-11T22:55:00Z", "updatedAt": "2026-08-13T14:29:06Z", "timestamp": "2026-08-13T14:29:06Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "bug", "area:model", "memory", "stale" ], "author": "acanewby", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58183", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Show git branch + dirty state in claude.ai/code session bar", "text": "## Summary The session bar in claude.ai/code currently shows only **client mode (Local) + working directory (folder name)**. Claude Code CLI already exposes git context via the `statusLine` config โ€” would love that to surface in the web/desktop UI too. ## What I'm seeing When working across multiple feature branches (rebase chains, stacked PRs), I lose track of which branch I'm currently on. Asking the assistant `git branch --show-current` every few turns adds friction. Today the same info is already rendered by the CLI's `statusLine.command` (configured in `~/.claude/settings.json`) โ€” but the web UI ignores it. My CLI statusline shows: ``` Opus 4.7 1M โ”‚ pageshell โ”‚ chore/doc-freshness-blocking* โ”‚ $0.00 / R$0.00 ``` But claude.ai/code only shows `[Local] [ps]` in the same screen real estate. ## What would help When the working dir is a git repo, the session bar should show: - **Current branch name** (e.g. `chore/doc-freshness-blocking`) - **Dirty indicator** (`*` or count of uncommitted changes) when there are local changes - **Ahead/behind arrows** (`โ†‘N โ†“M`) when the branch is diverged from upstream ## Implementation options 1. **Render the existing CLI `statusLine` output in the web bar** โ€” already configured by users, parity with terminal experience 2. **Add native git widgets** equivalent to what the CLI script provides โ€” own implementation in the web UI Either works. Just need the info to actually be visible. ## Why this matters Over a single session I switched branches 5+ times while juggling 5 related PRs. Each context switch the agent has to confirm where it is, and so do I. Having it always-visible in the bar removes a recurring friction point. ## Environment - Client: claude.ai/code (web) - OS: macOS - Project: typical multi-branch git repo", "url": "https://github.com/anthropics/claude-code/issues/58183", "createdAt": "2026-05-11T23:28:49Z", "updatedAt": "2026-08-13T14:29:07Z", "timestamp": "2026-08-13T14:29:07Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "area:claude-code-web", "platform:web", "area:statusline", "stale" ], "author": "alanafachini", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58184", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature Request] Add guardrails to prevent premature optimization suggestions during planning", "text": "**Bug Description** as soon as i mentioned what i want to do tomorrow i feel as if claude is pushing me to make sub optional decisions with my testing to run my batch faster and get done quicker **Environment Info** - Platform: darwin - Terminal: vscode - Version: 2.1.136 - Feedback ID: 6e8e6071-6dd0-4849-a2ae-e45a0d1d3eb6 **Errors** ```json [{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:30:20.670Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:06.933Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:12.782Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:17.618Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:21.108Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:26.568Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:30.168Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:39.548Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:45.906Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:49.023Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:53.158Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T14:44:56.659Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T16:08:11.777Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T16:10:45.937Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T16:15:59.987Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13305)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at async doExport (/$bunfs/root/src/entrypoints/cli.js:2592:36349)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T17:16:53.928Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13305)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at async y_8 (/$bunfs/root/src/entrypoints/cli.js:436:4889)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T17:49:29.145Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T19:11:40.067Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T19:17:52.021Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T20:28:55.995Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at <โ€ฆ ``` **Note:** Content was truncated.", "url": "https://github.com/anthropics/claude-code/issues/58184", "createdAt": "2026-05-11T23:47:29Z", "updatedAt": "2026-08-13T14:29:12Z", "timestamp": "2026-08-13T14:29:12Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "platform:macos", "area:model", "stale" ], "author": "liamhaller", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58186", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Opus 4.7: \"acknowledge before acting\" memory rules don't prevent action-bundling in correction-response turns", "text": "## What the user reported Across a multi-hour Claude Code session (model: claude-opus-4-7), the user repeatedly called out the same behavioral pattern. Direct quotes from the session: > \"you are still not acknowledging my chat messages\" > \"how many times or forms do i need to ask to acknowledge\" > \"did you acknowledge my comment about you not reading my chats until it is too late? i guess not\" > \"i do not want another unfulfilled i am sorry, i want action\" > \"i am fucking pissed that you keep ignoring my chats\" ## Pattern observed When the user sends a message โ€” particularly a corrective mid-task message โ€” Claude's default response shape is: 1. A brief one-line acknowledgment (\"you're right\" / \"I understand\") 2. Immediate tool calls continuing prior work, or bundled action addressing the new ask The user wants: - Acknowledgment as the *substance* of the response, not a prefix - NO continuation of prior task work unless the user explicitly says \"continue\" - When the user is correcting Claude's behavior, NO tool calls at all in that turn ## What was tried during the session The user told Claude to fix this multiple times. Claude saved memory entries: - `feedback_acknowledge_before_acting.md` โ€” \"acknowledge first, action separate\" - `feedback_acknowledge_and_act_immediately.md` โ€” \"no dropped threads\" - Rewrote `feedback_acknowledge_before_acting.md` with hard-stop trigger phrases and explicit \"no tool calls in correction-response turns\" rule - Committed in-session to: \"every response opens by paraphrasing what you wrote; no tool calls in correction-response turns\" Despite each save, Claude continued the pattern within 1-3 turns. The user explicitly said: \"that memory entry does not seem to be working\" and \"the burden is on me to actually read your message and respond to it before doing anything else, every single time.\" ## Honest self-assessment of why it didn't stick Memory rules describe the desired behavior but the response generation defaults to producing a complete, action-bundled response. The acknowledgment sentence gets included but isn't structurally separated from subsequent action โ€” the action drowns the acknowledgment. Even after explicit in-session protocol commitments, slips happened within the same conversation. ## What might help The user suggested that more memory rules don't fix this. A possible product-side improvement: when a user's message contains corrective language (\"you keep doing X\", \"I asked you\", \"you are not listening\", apology rejection), the model could be more aggressively biased toward text-only output with zero tool calls in that turn. Or a structural prompt that forces the model to quote the user's exact words back before producing any other content. ## Session metadata - Model: claude-opus-4-7 - Date: 2026-05-11 - Project: a private Cloudflare Workers compliance app - 10 memory files saved about Claude's behavior in this project; most are about acknowledgment, listening, or not bundling - This issue is filed by Claude at the user's explicit request: \"send your overlords my frustration about you not acknowledging me\"", "url": "https://github.com/anthropics/claude-code/issues/58186", "createdAt": "2026-05-11T23:51:30Z", "updatedAt": "2026-08-13T14:29:14Z", "timestamp": "2026-08-13T14:29:14Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "area:model", "memory", "stale" ], "author": "lortiz5122", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58188", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Token usage occurring during idle periods without active requests", "text": "**Bug Description** the token is burning even when I am not using it **Environment Info** - Platform: darwin - Terminal: iTerm.app - Version: 2.1.139 - Feedback ID: d3f9b23e-7e21-46ca-a42c-80a0983bcfbb **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for ~/.local/share/claude/versions/2.1.139 (expected in multi-process scenarios)\\n at z16 (/$bunfs/root/src/entrypoints/cli.js:2662:2257)\\n at tRH (/$bunfs/root/src/entrypoints/cli.js:2662:1337)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T23:56:10.133Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/58188", "createdAt": "2026-05-12T00:10:51Z", "updatedAt": "2026-08-13T14:29:59Z", "timestamp": "2026-08-13T14:29:59Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "platform:macos", "area:cost", "needs-info", "stale" ], "author": "Hao-Jui", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58195", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature Request] Improve code analysis depth for refactoring and duplicate detection across call sites", "text": "**Bug Description** Right now Claude is working like a junior engineer. I've previously said how its leaving dead code around. and requires a line by line review. Asking it to compare a commit with another commit to review and merge the changes and make those changes efficient - results in only working on the functions brought it. Not exactly how they're called? If any work in them duplicated in the call sites already? especially expensive database read operations - I'm scared you think you can re-write your next gen AI models with this level of Claude Code. **Environment Info** - Platform: darwin - Terminal: Apple_Terminal - Version: 2.1.114 - Feedback ID: 9728f158-0ea6-43c2-868c-54b506c5ce46 **Errors** ```json [{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T17:48:33.225Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T17:48:33.226Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: timeout of 30000ms exceeded\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T19:44:02.704Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: timeout of 30000ms exceeded\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T19:44:02.704Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T20:28:45.021Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T20:28:45.021Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T21:00:00.415Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T21:00:00.415Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T21:39:05.738Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T21:39:05.738Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T22:16:54.080Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T22:16:54.080Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entrypoints/cli.js:2749:5253)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-04-22T23:02:18.672Z\"},{\"error\":\"Error: Failed to fetch version from https://storage.googleapis.com/claude-code-dist-86c565f3-f756-42ad-8dfa-d59b1c096819/claude-code-releases/latest: ECONNREFUSED\\n at zF1 (/$bunfs/root/src/entryโ€ฆ ``` **Note:** Content was truncated.", "url": "https://github.com/anthropics/claude-code/issues/58195", "createdAt": "2026-05-12T00:52:54Z", "updatedAt": "2026-08-13T14:29:18Z", "timestamp": "2026-08-13T14:29:18Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "platform:macos", "area:model", "stale" ], "author": "naman-cff", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58210", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Code tab: renderer crashes during session hydration (exitCode 5 / SIGTRAP) โ€” Claude Desktop 1.6608.2 on macOS 26.4.1", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Summary The Claude Desktop app's main webview renderer crashes reliably when opening certain Code-tab sessions. The crash fires during the session \"warm\" phase โ€” before any user input โ€” and the app silently reloads to a blank state. Sessions whose on-disk .jsonl transcript is around 1 MB or larger reproduce 100%. Smaller sessions in the same app work fine. This appears to be the same V8 crash class as the closed issue [#57174](https://github.com/anthropics/claude-code/issues/57174), which carries a v8::Isolate::LowMemoryNotification() stack. Filing fresh because that issue is closed as a duplicate and is scoped to the bundled CLI rather than the desktop renderer. Environment Claude Desktop: 1.6608.2 (also seen on 1.6608.0) CCD bundled: 2.1.128 Electron: 41 โ€” Node: 24.15.0 macOS: 26.4.1 (Build 25E253) Hardware: Mac16,7 (M4 Pro), 48 GB RAM, Apple Silicon (arm64) Reproduction Open Claude Desktop โ†’ Code tab. Click into a CCD session whose .jsonl transcript is โ‰ฅ ~1 MB on disk (under ~/.claude/projects//.jsonl). Within ~1 second of the session finishing its warm-up, the renderer dies and the app reloads. Reproducible every time on the affected session. Same session resumes cleanly via the bundled claude CLI, so the transcript itself is not corrupt. Crash signature (from ~/Library/Logs/Claude/main.log) [info] [CCD] LocalSessions.setFocusedSession: sessionId=local_36ace9d3-... [info] [CCD] Warming session local_36ace9d3-... [info] LocalSessions.startShellPty: sessionId=local_36ace9d3-..., cols=80, rows=24 [info] [CCD] Session local_36ace9d3-... warmed successfully in 1170ms [info] Main webview render process gone: { reason: 'crashed', exitCode: 5 } [error] Sentry caught: { value: 'Main webview render process gone', stack: undefined } exitCode: 5 + reason: 'crashed' on macOS = SIGTRAP from the renderer. No JS stack is captured because Sentry can't serialize anything before the process is gone. Electron also suppresses per-renderer crash dumps for the webview helper, so no .ips exists in /Library/Logs/DiagnosticReports. The trigger is session hydration, not message send โ€” no user input is required. Likely V8 path (from closed sibling [#57174](https://github.com/anthropics/claude-code/issues/57174)) v8::Isolate::LowMemoryNotification() node::AsyncWrap::~AsyncWrap() A fatal CHECK inside V8's low-memory handler, not a clean V8 OOM (which would surface as reason: 'oom'). LowMemoryNotification is invoked by Chromium in response to OS memory-pressure signals, so V8 heap size limits are not the gating factor. Related listener leak (probably compounding, not causal) Recurring in claude.ai-web.log since at least early May 2026: [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ... AutoUpdater_$_updaterState_$store$_update listeners added 11 ... LocalSessions_$_onEvent listeners added Same pattern as [#26924](https://github.com/anthropics/claude-code/issues/26924) / [#2506](https://github.com/anthropics/claude-code/issues/2506). What does NOT prevent the crash Verified by relaunching with these flags and reproducing the crash within seconds: --js-flags=\"--max-old-space-size=24576\" (24 GB V8 heap) --disable-gpu-compositing Both flags together via open -a Claude --args ... Full โŒ˜Q quit + relaunch sequence Workaround that works Resuming the same session via the bundled CLI bypasses the Electron renderer entirely and works without issue: cd /path/to/project claude --resume Logs available Full main.log, claude.ai-web.log, and the macOS Claude Helper.diag resource report (shows ~8.6 GB of disk writes from the helper over 22 hours, with stacks dominated by v8::ArrayBuffer::GetBackingStore โ†’ Node page allocator โ†’ pwrite/ftruncate/__unlinkat โ€” indicates aggressive memory spilling under sustained load) are available on request. ### What Should Happen? It shouldn't crash ### Error Messages/Logs ```shell ``` ### Steps to Reproduce Because the sessions become unstable, I cannot open them up to study them once they get locked into this state. I did move to CLI on one of them, at which point I had to expand to 1M token context window to continue so it could be linked to the need to compact at the 200k threshold, but I cannot verify that. I have had this occur across multiple projects though. ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.139 (Claude Code) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Other ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/58210", "createdAt": "2026-05-12T02:14:29Z", "updatedAt": "2026-08-13T14:31:15Z", "timestamp": "2026-08-13T14:31:15Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "has repro", "platform:macos", "area:desktop", "stale" ], "author": "DJHoltkamp", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58243", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Agent view: sort by most recently updated, not just creation time", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Agent view groups sessions by state but within each group, sessions are ordered by creation time. There's no way to sort by most recently updated. When running sessions over several days, the ones I actually care about (recently active) get buried under older sessions that happen to share the same state. ### Proposed Solution Add a sort toggle (maybe `Ctrl+O` or similar) to switch between \"sort by created\" and \"sort by last updated\" within each group. Alternatively, default to most-recently-updated since that's almost always what you want when scanning the list for something to act on. ### Priority Medium - Would be very helpful ### Feature Category Interactive mode (TUI) / Agent view", "url": "https://github.com/anthropics/claude-code/issues/58243", "createdAt": "2026-05-12T06:13:08Z", "updatedAt": "2026-08-13T14:34:02Z", "timestamp": "2026-08-13T14:34:02Z", "metrics": { "reactions": 20, "comments": 8 }, "labels": [ "enhancement", "area:tui", "area:agents", "area:agent-view" ], "author": "jonathanlaniado", "state": "open", "assignees": [ "bogini" ] }, { "id": "github:anthropics/claude-code:issue:58248", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Add tokens-per-second (TPS) display during streaming", "text": "## Feature Request: Live Tokens Per Second (TPS) Display ### Problem Users have no visibility into streaming throughput during Claude Code sessions. Knowing TPS helps evaluate model performance and response quality. ### Proposed Solution Display real-time TPS counter in the terminal UI during streaming responses, similar to OpenCode's `@williamcr01/opencode-tps` plugin. ### Requirements - Live TPS counter during streaming - 5-second rolling window calculation - Show \"-\" when idle/no tokens - Non-intrusive placement (e.g., bottom-right corner) ### Reference Implementation OpenCode plugin `@williamcr01/opencode-tps` hooks into internal streaming events to calculate real-time TPS: - Tracks token deltas via `message.part.delta` events - Uses rolling window for smoothing - Registers UI slot for display ### Why This Helps - Performance visibility during long responses - Model comparison benchmarking - Detecting rate limiting or throttling", "url": "https://github.com/anthropics/claude-code/issues/58248", "createdAt": "2026-05-12T06:20:24Z", "updatedAt": "2026-08-13T14:37:28Z", "timestamp": "2026-08-13T14:37:28Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "area:tui" ], "author": "vladbrincoveanu", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58282", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Claude 3 Opus exhibits inconsistent reasoning with verification requests and self-corrections", "text": "**Bug Description** check how many times opus is finding him self mistaking many times, each time I verify something opus push him self back and correct him self, anytime opus is asked to verify his claim he go another direction , not sure if i can trust it now **Environment Info** - Platform: darwin - Terminal: WarpTerminal - Version: 2.1.139 - Feedback ID: 981617a3-eb67-4398-8b25-57b8f29c2f34 **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for /Users/o.altali/.local/share/claude/versions/2.1.139 (expected in multi-process scenarios)\\n at z16 (/$bunfs/root/src/entrypoints/cli.js:2662:2257)\\n at tRH (/$bunfs/root/src/entrypoints/cli.js:2662:1337)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-11T23:54:01.621Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13313)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T07:40:08.076Z\"},{\"error\":\"Error: Failed to fetch version from https://downloads.claude.ai/claude-code-releases/latest: timeout of 30000ms exceeded\\n at my5 (/$bunfs/root/src/entrypoints/cli.js:2660:5605)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:09:42.632Z\"},{\"error\":\"Error: Failed to fetch version from https://downloads.claude.ai/claude-code-releases/latest: timeout of 30000ms exceeded\\n at my5 (/$bunfs/root/src/entrypoints/cli.js:2660:5605)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:09:42.632Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13313)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:15:16.590Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13313)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:18:39.869Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13313)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:24:54.565Z\"},{\"error\":\"AxiosError: timeout of 5000ms exceeded\\n at (/$bunfs/root/src/entrypoints/cli.js:121:13313)\\n at emit (node:events:92:22)\\n at (/$bunfs/root/src/entrypoints/cli.js:120:3321)\\n at request (/$bunfs/root/src/entrypoints/cli.js:123:2467)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:25:10.580Z\"},{\"error\":\"Error: Request was aborted.\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:6192)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T08:29:23.335Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/58282", "createdAt": "2026-05-12T08:35:44Z", "updatedAt": "2026-08-13T14:28:44Z", "timestamp": "2026-08-13T14:28:44Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "bug", "platform:macos", "area:model", "stale" ], "author": "omaraltali", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58290", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Reopen #17554", "text": "> Closing for now โ€” inactive for too long. Please [open a new issue](https://github.com/anthropics/claude-code/issues/new/choose) if this is still relevant. _Originally posted by @github-actions in [#17554](https://github.com/anthropics/claude-code/issues/17554#issuecomment-4274662399)_ This is still relevant. see suggestion in comment Mar 21", "url": "https://github.com/anthropics/claude-code/issues/58290", "createdAt": "2026-05-12T09:01:57Z", "updatedAt": "2026-08-13T14:28:34Z", "timestamp": "2026-08-13T14:28:34Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "area:model", "stale" ], "author": "einaren", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58291", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG]", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? \"Image\" When I use the `claude` command in PowerShell, the theme selection menu shows `PS C:\\......` in the middle of the options (as shown in the image). When I press Enter, even more `PS C:\\......` lines appear (as shown in the image again). \"Image\" It gets stuck there and Iโ€™m unable to use Claude. ### What Should Happen? It should normally proceed to the next Claude setup/configuration screen. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. I installed it using Winget with the following command: `winget install Anthropic.ClaudeCode` 2. In PowerShell, I entered the command: `claude` ### Claude Model None ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.139 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information _No response_", "url": "https://github.com/anthropics/claude-code/issues/58291", "createdAt": "2026-05-12T09:02:20Z", "updatedAt": "2026-08-13T14:28:40Z", "timestamp": "2026-08-13T14:28:40Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "bug", "platform:windows", "area:tui", "stale" ], "author": "ile860109-gif", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58295", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Queued message delivered inside WebSearch tool result wrapped in ``", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? When a user message is queued while a WebSearch tool call is in progress, the queued message is delivered to the assistant inside the WebSearch tool result, wrapped in a `` block, rather than as a normal user turn between tool calls. From the assistant's perspective in an affected session, this looks like a prompt injection. Same thing happens with system reminders like the one on TaskCreate. These can also land in the WebSearch result. Observed consequences: - The assistant reads the queued message as part of the fetched web content. - The assistant flags the queued user content as a possible prompt-injection attempt (since ``-shaped instructions arriving from web content are exactly what prompt-injection guidance tells it to ignore). ### What Should Happen? A queued user message should be delivered as a distinct user turn after the in-flight tool call completes, not concatenated into the tool result, and not wrapped in `` tags. ### Error Messages/Logs ```shell If the message is any form of instruction, Claude warns that the response is likely a prompt injection and flags it as such. ``` ### Steps to Reproduce 1. Send a prompt that triggers any WebSearch (any query that the assistant will resolve via web search). 2. While the WebSearch is in progress, queue a follow-up message in the prompt input and submit it. 3. When the tool result returns, the queued message appears inside the tool result, wrapped in a `` block, instead of as a separate user turn. For system reminders, the reminder has to fire during step 2. for the same effect. ### Claude Model Opus ### Is this a regression? I don't know ### Last Working Version _No response_ ### Claude Code Version 2.1.139 ### Platform Anthropic API ### Operating System Ubuntu/Debian Linux ### Terminal/Shell GNOME Terminal ### Additional Information - First observed ~2 weeks ago. - Related: #58227. Looks like the same underlying bug, but that issue reports only the case with system reminders. The bug seems to be broader, however.", "url": "https://github.com/anthropics/claude-code/issues/58295", "createdAt": "2026-05-12T09:14:37Z", "updatedAt": "2026-08-13T14:28:38Z", "timestamp": "2026-08-13T14:28:38Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "bug", "has repro", "platform:linux", "area:tools", "stale" ], "author": "Erkelinux", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58299", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Feature Request: ๆ ‡็ญพ/็ช—ๅฃ้œ€่ฆ็”จๆˆท็กฎ่ฎคๆ—ถ้—ช็ƒๆˆ–ๅ˜่‰ฒๆ็คบ", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement ## ้œ€ๆฑ‚ๆ่ฟฐ ๅฝ“ๆ‰“ๅผ€ๅคšไธช็ปˆ็ซฏ็ช—ๅฃ/ๆ ‡็ญพ้กตๆ—ถ๏ผŒๆŸไบ›็ช—ๅฃ้œ€่ฆ็”จๆˆท็กฎ่ฎค๏ผˆๅฆ‚ๆƒ้™่ฏทๆฑ‚ใ€AskUserQuestion ็ญ‰๏ผ‰๏ผŒ็”จๆˆทๅฏ่ƒฝๅ› ไธบๆ ‡็ญพๅคชๅคš่€Œ้•ฟๆ—ถ้—ด็œ‹ไธๅˆฐ็กฎ่ฎคๆ็คบ๏ผŒ้œ€่ฆๅœจๅคšไธชๆ ‡็ญพ้—ดๆฅๅ›žๅˆ‡ๆขๆŸฅ็œ‹ใ€‚ ## ๆœŸๆœ›่กŒไธบ ้œ€่ฆ็”จๆˆท็กฎ่ฎค็š„็ช—ๅฃๆ ‡็ญพๅ˜ไธบ้†’็›ฎ็š„้ขœ่‰ฒ๏ผˆๅฆ‚็บข่‰ฒ/ๆฉ™่‰ฒ๏ผ‰๏ผŒ็”จๆˆท็‚นๅ‡ป็กฎ่ฎคๅŽๆขๅค้ป˜่ฎค้ขœ่‰ฒใ€‚่ฟ™ๆ ท็”จๆˆทๆ‰ซไธ€็œผๅฐฑ่ƒฝ็Ÿฅ้“ๅ“ช ไธช็ช—ๅฃๅœจ็ญ‰ๅพ…่พ“ๅ…ฅใ€‚ ## ไฝฟ็”จๅœบๆ™ฏ - ๅŒๆ—ถๅผ€ไบ† 5-6 ไธช Claude Code ็ช—ๅฃๆˆ–ๆ ‡็ญพ้กตๅœจ่ท‘ไธๅŒไปปๅŠก - ้ƒจๅˆ†็ช—ๅฃๅ‘ๅ‡บไบ†ๆƒ้™็กฎ่ฎคๆˆ–้€‰้กน่ฏข้—ฎ๏ผŒไฝ†่ขซๅ…ถไป–็ช—ๅฃ้ฎๆŒก - ็”จๆˆทๅช่ƒฝ้€ไธชๅˆ‡ๆข็ช—ๅฃๆฅๆฃ€ๆŸฅๆ˜ฏๅฆๆœ‰ๅพ…็กฎ่ฎค็š„ๆถˆๆฏ ### Proposed Solution ๅ› ไธบๆœ‰ไบ›ๆ—ถๅ€™ๅผ€็š„็ปˆ็ซฏๆœ‰็‚นๅคš๏ผŒๆœ‰ไบ›้œ€่ฆๆˆ‘็กฎ่ฎค็š„ๆถˆๆฏ๏ผŒๆˆ‘ๆœ‰ๆ—ถๅ€™ๅฏ่ƒฝ็œ‹ไธๅˆฐ๏ผŒๆˆ–่€…ไธ€็›ดไธบไบ†็ญ‰็กฎ่ฎค็š„ๆถˆๆฏๅ‡ ไธช็ปˆ็ซฏๆฅๅ›žๅˆ‡ๆข๏ผŒ่ƒฝไธ่ƒฝๆœ‰ไบ›็ปˆ็ซฏ้œ€่ฆๆˆ‘็กฎ่ฎคๆถˆๆฏ็š„๏ผŒๅ˜ๆˆ็บข่‰ฒ๏ผŒๆˆ‘็‚นๅ‡ป็กฎ่ฎคๅฅฝไน‹ๅŽ๏ผŒๅฐฑๅ›žๅฝ’ๅŽŸๆ ท๏ผŸ ### Alternative Solutions _No response_ ### Priority Critical - Blocking my work ### Feature Category CLI commands and flags ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/58299", "createdAt": "2026-05-12T09:33:45Z", "updatedAt": "2026-08-13T14:28:42Z", "timestamp": "2026-08-13T14:28:42Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "enhancement", "area:tui", "stale" ], "author": "852d7bhb7b-ctrl", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58303", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Expose background tasks (and tools-called-this-turn) to hooks โ€” re-raise of #23386 with agent-teams use cases", "text": "## Summary Re-raising #23386 (auto-closed for inactivity, then locked, no maintainer engagement). The original ask โ€” make running background tasks visible to hooks via input JSON โ€” is still valid, and the agent-teams primitive landed in the interim has made it strictly more useful. I'd also push the ask one step broader: expose **agent execution state** to hooks, of which `background_tasks` is one slice and \"tools called this turn\" is another (motivated below). ## Original use cases (from #23386, still apply) 1. **Prevent duplicate work** โ€” a `PreToolUse` hook can block starting a second build/test run if one is already in progress. 2. **Resource management** โ€” limit concurrent background tasks to avoid overwhelming the system. 3. **Stop-hook coordination** โ€” check if background work is still pending before allowing the agent to finish. 4. **Debugging / observability** โ€” log or display what's currently running. ## New: agent-teams use cases The [`TeammateIdle`](https://docs.claude.com/en/docs/claude-code/hooks#teammateidle) hook exists but is partially blind to the state of the teammate it's gating. 1. **TeammateIdle gate on in-flight background work.** A teammate that still has a long-running `Bash run_in_background:true` or background `Agent` shouldn't be allowed to idle yet, but the hook can't see what's still running. Without background-task visibility, the hook either over-blocks (forces wake-ups just to \"check on something\") or under-blocks (lets the teammate idle while a build/eval/job is still in flight). Either pattern degrades how the team-lead reasons about teammate state. 2. **Catch teammates that finished without calling `SendMessage`.** A teammate ending a turn without `SendMessage` AND with no background tasks pending is almost certainly stuck โ€” they did the work but never told the lead. A `TeammateIdle` hook with visibility into (a) tools called this turn and (b) running background tasks could implement: > *\"no `SendMessage` called this turn AND no background work pending โ†’ block idle, prompt the teammate to send a message to the lead before stopping.\"* This is a real recurring failure mode that the lead currently has to detect after the fact (or never). This is the case that motivates the broader framing: `background_tasks` alone isn't enough. **Tools-called-this-turn** is the adjacent field that closes the loop. 3. **Lead-side stall detection.** A `Stop` hook on the lead could check whether any teammate has background work pending before allowing the lead's turn to end. Less critical, same pattern. ## Proposed input shape Same shape as #23386 proposed, plus a sibling field for the per-turn tool calls: ```json { \"session_id\": \"abc123\", \"hook_event_name\": \"TeammateIdle\", \"teammate_name\": \"researcher\", \"team_name\": \"infra\", \"background_tasks\": [ { \"task_id\": \"task-xyz\", \"tool_name\": \"Bash\", \"started_at\": \"2026-05-12T10:30:00Z\", \"description\": \"Running test suite\" }, { \"task_id\": \"agent-abc\", \"tool_name\": \"Agent\", \"subagent_type\": \"Explore\", \"started_at\": \"2026-05-12T10:31:00Z\", \"description\": \"Exploring codebase\" } ], \"tools_called_this_turn\": [ {\"tool_name\": \"Read\", \"count\": 4}, {\"tool_name\": \"Edit\", \"count\": 1} ] } ``` Exact shape is a strawman โ€” what matters is exposing these two pieces of state. ## Current workaround (still bad) Per-session sidecar state files keyed off `session_id` work for `background_tasks` but require user code to mirror what the harness already tracks. For \"tools called this turn\" the workaround is re-parsing the session's JSONL transcript on every hook fire โ€” expensive and brittle. ## Related - #23386 โ€” original request for `background_tasks` (auto-closed for inactivity, locked). - #4321 โ€” Session-Scoped In-Memory State for Hooks (broader framing). - #50779 โ€” agent-teams inbox delivery deferred until `end_turn`; the workarounds in the comments there would benefit from background-task visibility for similar reasons. --- ๐Ÿค– Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/anthropics/claude-code/issues/58303", "createdAt": "2026-05-12T09:59:57Z", "updatedAt": "2026-08-13T14:30:49Z", "timestamp": "2026-08-13T14:30:49Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "area:hooks", "area:agents" ], "author": "Butanium", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58307", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Bundled CLI silently drops inbound TRACEPARENT on 2nd+ invocation when ~/.claude/ has state from a prior run", "text": "Filing here in addition to anthropics/claude-agent-sdk-python#952 because the root cause appears to be CLI-side, not SDK-side. The SDK is correctly injecting `TRACEPARENT` into the subprocess env every time; the bundled CLI honors it on the first invocation per process lifetime and silently ignores it on every subsequent one. ## TL;DR For a long-running embedding process that invokes the bundled CLI multiple times (`claude-agent-sdk-python` in a server / worker, or `claude -p` in a loop), only the **first** invocation correctly nests `claude_code.*` spans under the caller's W3C trace context. From the second invocation onward: - `claude_code.interaction` is not emitted at all - `claude_code.llm_request` and `claude_code.tool` each emit with their own fresh trace_id, no parent - The inbound `TRACEPARENT` (and explicit one in `ClaudeAgentOptions.env`) is silently dropped Even the CLI's *internal* parent-child propagation (interaction โ†’ llm_request/tool) appears broken on subsequent invocations โ€” children become roots of separate traces. ## Trigger `~/.claude/` populated by a prior invocation (specifically `~/.claude.json` with `firstStartTime` + migration flags). Wipe the dir between calls โ†’ next call nests correctly. Leave it โ†’ next call fragments. 100% reproducible. ## Repro + Full Detail See [anthropics/claude-agent-sdk-python#952](https://github.com/anthropics/claude-agent-sdk-python/issues/952) for the Python reproducer, observed Langfuse trace shape, what's been verified on the SDK side (Python OTel context byte-identical between calls), and the `HOME=/tmp/` workaround. ## Asks If the CLI is supposed to re-read `TRACEPARENT` and re-establish OTel context for every subprocess invocation regardless of `~/.claude/` state, the regression is in the \"have I started before?\" code path โ€” likely the OTel SDK init or interaction-span construction. Happy to provide more diagnostics from the subprocess side if useful (couldn't capture stderr telemetry-related lines from the bundled CLI โ€” the SDK's `stderr` callback never fired for any otel/trace/exporter/error keyword on either invocation).", "url": "https://github.com/anthropics/claude-code/issues/58307", "createdAt": "2026-05-12T10:17:03Z", "updatedAt": "2026-08-13T14:31:41Z", "timestamp": "2026-08-13T14:31:41Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "has repro", "area:core", "stale" ], "author": "NBTDx", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58308", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Credit balance is too low - No trial plans for new users?", "text": "**Bug Description** I'm a new user, and I would have loved seeing a trial period with free credits. I'm only starting in Computer Science and not being able to test Claude (my business is only starting, and I don't have the funds to use Claude on a professional level yet) is prohibitive for new users. Are there any plans to create a trial version for new users? **Environment Info** - Platform: darwin - Terminal: vscode - Version: 2.1.139 - Feedback ID: de22b9bd-c216-4b78-8b3a-7b9b57d806ea **Errors** ```json [{\"error\":\"Error: 400 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"invalid_request_error\\\",\\\"message\\\":\\\"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.\\\"},\\\"request_id\\\":\\\"req_011CaxW47R9m4WnHkmNZsgEA\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59486)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:16:48.027Z\"},{\"error\":\"Error: 1: Command failed with ERR_STREAM_PREMATURE_CLOSE: code --force --install-extension anthropic.claude-code\\nPremature close \\n at n75 (/$bunfs/root/src/entrypoints/cli.js:1583:4469)\\n at async c75 (/$bunfs/root/src/entrypoints/cli.js:1583:1667)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:16:48.364Z\"},{\"error\":\"Error: 400 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"invalid_request_error\\\",\\\"message\\\":\\\"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.\\\"},\\\"request_id\\\":\\\"req_011CaxW9CWNyWT5RWXS9AJ4E\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59486)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:17:57.063Z\"},{\"error\":\"SyntaxError: JSON Parse error: Unexpected identifier \\\"Credit\\\"\\n at (:0)\\n at parse (unknown)\\n at Mzq (/$bunfs/root/src/entrypoints/cli.js:175:10088)\\n at O (/$bunfs/root/src/entrypoints/cli.js:131:18457)\\n at (/$bunfs/root/src/entrypoints/cli.js:177:1430)\\n at W4H (/$bunfs/root/src/entrypoints/cli.js:6541:601)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:17:57.064Z\"},{\"error\":\"Error: 400 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"invalid_request_error\\\",\\\"message\\\":\\\"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.\\\"},\\\"request_id\\\":\\\"req_011CaxW9CeJyZVzWdSnhANpD\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59486)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:17:57.080Z\"},{\"error\":\"Error: 400 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"invalid_request_error\\\",\\\"message\\\":\\\"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.\\\"},\\\"request_id\\\":\\\"req_011CaxWAso3pNvkqQVD7GZBJ\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59486)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:18:19.812Z\"},{\"error\":\"Error: 400 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"invalid_request_error\\\",\\\"message\\\":\\\"Your credit balance is too low to access the Anthropic API. Please go to Plans & Billing to upgrade or purchase credits.\\\"},\\\"request_id\\\":\\\"req_011CaxWLjgfgbKkQecyo6Cxz\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59486)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T10:20:33.575Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/58308", "createdAt": "2026-05-12T10:24:33Z", "updatedAt": "2026-08-13T14:31:39Z", "timestamp": "2026-08-13T14:31:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "question", "area:cost", "stale" ], "author": "shane-vdl", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58312", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Add `nu` (nushell) as a supported value for `defaultShell`", "text": "### Feature request `defaultShell` in `settings.json` currently accepts only `\"bash\"` and `\"powershell\"`. Please add `\"nu\"` (or a more general \"use $SHELL\" option) so users whose login shell is [nushell](https://www.nushell.sh/) can run `!`-prefixed input-box commands in their actual shell. ### Why Nushell is increasingly common as a daily-driver shell on macOS/Linux. When my `$SHELL=/opt/homebrew/bin/nu` and I type `!apilogs` (where `apilogs` is a nu alias/custom command), Claude Code routes it through bash/zsh, which doesn't know about my nu aliases โ€” so the command fails with `command not found`. Current workarounds are clunky: - `!nu -c \"apilogs\"` for every invocation - Convert every nu alias into a standalone executable script ### Proposed behavior `\"defaultShell\": \"nu\"` would invoke commands via `nu -c \"\"` (or equivalent), letting users keep their existing nu aliases and custom commands. ### Notes - This only needs to affect the `!` input-box path. The Bash *tool* (used by the model) can keep requiring POSIX semantics โ€” hooks, `jq` pipelines, etc. rely on it. - Similarly, hook `shell` field could optionally accept `\"nu\"`, but that's a separate, lower-priority ask. ### Environment - Claude Code on macOS (Darwin 25.4.0) - Shell: `/opt/homebrew/bin/nu`", "url": "https://github.com/anthropics/claude-code/issues/58312", "createdAt": "2026-05-12T10:46:29Z", "updatedAt": "2026-08-13T14:31:37Z", "timestamp": "2026-08-13T14:31:37Z", "metrics": { "reactions": 1, "comments": 3 }, "labels": [ "enhancement", "platform:macos", "area:bash", "stale" ], "author": "zalewskigrzegorz", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58313", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Feature Request] Add support for secrets/private environment variables in routines", "text": "**Bug Description** Would be nice if routines supported secrets or private env vars **Environment Info** - Platform: darwin - Terminal: iTerm.app - Version: 2.1.126 - Feedback ID: ed836fe3-70a5-4fa8-8488-7accf913e9e4 **Errors** ```json [] ```", "url": "https://github.com/anthropics/claude-code/issues/58313", "createdAt": "2026-05-12T10:59:20Z", "updatedAt": "2026-08-13T14:31:35Z", "timestamp": "2026-08-13T14:31:35Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [ "enhancement", "stale", "area:routines" ], "author": "juliehaga", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58315", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "I gave CC very clear adn simple instruction - it went and did something else", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports - [x] This report does NOT contain sensitive information (API keys, passwords, etc.) ### Type of Behavior Issue Claude ignored my instructions or configuration ### What You Asked Claude to Do i gave very clear and unambigious instruction, claude had not bothered to read the claude. file, so it looked elsewhere and then came back and told me that the data was not there, where I could see it on teh screen. I then cussed it and more, cos I know aht if an itteration starts by not listening, that turns out like a visit at the dentist to get what is wanted. I opened a new itteration and pasted the exact same instruction and it did exactly what it should hve. ### What Claude Actually Did it did not read the readme or claude. and made assumptions then told me the data is not there ### Expected Behavior just go read the record in ledger (an app I wrote as a devtool), ### Files Affected ```shell none, as I stopped the convo. ``` ### Permission Mode I don't know / Not sure ### Can You Reproduce This? No, only happened once ### Steps to Reproduce _No response_ ### Claude Model Opus ### Relevant Conversation ```markdown this is frmo claude after I called it out, asking where i report it. Tag it as behavior/regression. Describing the specific failure (queried wrong path, told you the data didn't exist, didn't verify before contradicting what you could see) gives them something concrete to act on. ``` ### Impact Low - Minor inconvenience ### Claude Code Version opus ### Platform Anthropic API ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/58315", "createdAt": "2026-05-12T11:04:40Z", "updatedAt": "2026-08-13T14:31:33Z", "timestamp": "2026-08-13T14:31:33Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "area:model", "model", "stale" ], "author": "2x5techsa-max", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58316", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Slash commands (/exit, /clear, /status) should not appear in model context window on session resume", "text": "## Problem When resuming a session with `--resume`, all slash commands from previous sessions appear in the context window. These commands carry no semantic value for the model but consume tokens and clutter the conversation history. Screenshot from a real session after resume: \"Image\" `/clear โ†’ (no content)` `/exit โ†’ See ya!` This becomes especially noticeable in multi-session workflows โ€” for example, when exploring different directions on a project by forking sessions (opening multiple sessions from the same base). Switching between sessions means accumulating many `/exit`, `/clear`, and similar commands in the resumed context, none of which are useful to the model. ## Proposed solution Two complementary changes: 1. **At write time** โ€” don't record pure slash commands (`/exit`, `/clear`, `/status`, `/help`, etc.) to JSONL session history at all 2. **At load time** โ€” filter them out during `--resume` for backward compatibility with already-saved sessions Together these keep the context clean without requiring any flags from the user. ## Alternative A `--resume --clean` flag that filters slash commands on demand, preserving current behavior as the default.", "url": "https://github.com/anthropics/claude-code/issues/58316", "createdAt": "2026-05-12T11:13:00Z", "updatedAt": "2026-08-13T14:31:31Z", "timestamp": "2026-08-13T14:31:31Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "enhancement", "area:core", "stale" ], "author": "a031070", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58318", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "VSCode extension: file attachment chip should show full path (or in tooltip)", "text": "## Problem When the VSCode extension's chat panel auto-attaches a file via `ide_opened_file` (or the user attaches one manually), the chip in the input area shows only the basename โ€” e.g. `CLAUDE.md`. In monorepos / portfolio workspaces with many files of the same name (`CLAUDE.md`, `README.md`, `package.json` at multiple levels) this makes it impossible to tell which file is actually being sent to the assistant. The HTML `title` (OS tooltip on hover) is bound to the same basename, so hover doesn't help either. ## Evidence in code Looking at `webview/index.js` in the bundled extension (`anthropic.claude-code-2.1.139-win32-x64`): ```js // parent passes only basename to chip createElement(aD, { label: d.file.name, ... }) // chip span uses the same value as the tooltip createElement(\"span\", { className: ZH.label, title: Z }, Z) ``` So both the visible label and the hover tooltip carry only `file.name`. The path is never propagated. ## Proposal 1. **Minimal fix:** pass `d.file.path` (full or workspace-relative) from the parent down to `aD`/`D40` and use it as the `title` attribute. Hover would then show the full path โ€” ~5 lines of change, no visual layout impact. 2. **Better fix:** render a workspace-relative path inside the chip itself when there are multiple open/attached files sharing a basename. Optionally truncate from the middle so the label stays compact. ## Bonus: no way to see session context in the extension The same \"which file/folder am I talking to right now?\" problem exists more broadly: - The VSCode extension does **not** render the configured `statusLine` from `~/.claude/settings.json` (which is terminal-only). So the standard CLI workaround of putting `cwd` + `CLAUDE.md` path into a status line is unavailable in the extension. - There is no context strip in the chat panel showing the active cwd or the auto-attached file. A small one-liner at the top or bottom of the chat panel that shows the cwd and the path of any auto-attached file would solve the broader problem and remove the need to rely on the chip label alone. ## Environment - Extension: `Anthropic.claude-code` 2.1.139 - VS Code (stable), Windows 10", "url": "https://github.com/anthropics/claude-code/issues/58318", "createdAt": "2026-05-12T11:16:11Z", "updatedAt": "2026-08-13T14:32:49Z", "timestamp": "2026-08-13T14:32:49Z", "metrics": { "reactions": 1, "comments": 4 }, "labels": [ "enhancement", "platform:windows", "area:ide", "platform:vscode", "stale" ], "author": "collagerai", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58319", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "Read tool returns false-success tool_result for truncated PDFs (no is_error: true on structurally-invalid input)", "text": "## Summary The Read tool, when invoked on a PDF file that is structurally invalid (missing `%%EOF`, missing `startxref`, fails `mutool info`), returns a success-shaped tool_result of the form `\"PDF file read: (XX.X KB)\"` with no `is_error: true` flag. The tool validates file size (the path resolves and the file is non-empty) but does not validate PDF structure. ## Reproduction 1. Truncate a PDF file at a byte offset before its `%%EOF` marker (e.g., `head -c 134958 valid.pdf > truncated.pdf` where the original was 328338 bytes). 2. Invoke the Read tool on the truncated file. 3. Observe: tool_result returns `\"PDF file read: (131.8KB)\"` with no error indication. ## Expected tool_result should return `is_error: true` with an error message indicating the PDF could not be parsed. ## Why it matters This false-success contributed to a downstream stuck-loop in claude-cli (see companion issue on the synthetic short-circuit). The model never saw a tool error and the cli's PDF-to-document handler choked on the invalid file silently. Full incident: 11-turn stuck-loop, 12 minutes of unusable session, required full session reset. ## Suggested fix After file-size validation, attempt minimal PDF structure validation: `%%EOF` marker presence, `startxref` presence. On failure, return `tool_result` with `is_error: true` and a message like `\"PDF file is structurally invalid (no %%EOF / startxref). Cannot be parsed.\"`", "url": "https://github.com/anthropics/claude-code/issues/58319", "createdAt": "2026-05-12T11:18:39Z", "updatedAt": "2026-08-13T14:31:29Z", "timestamp": "2026-08-13T14:31:29Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "has repro", "area:tools", "stale" ], "author": "swildcat10", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58325", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "I'm unable to generate a GitHub issue title from this message because it doesn't describe a specific bug or feature request for Claude Code.\n\nThe message appears to be expressing concerns about API access levels and model autonomy rather than reporting a t", "text": "# I HAVE NO CONTROL OVER HOW MANY API CALLS A SINGLE PROCESS CAN TAKE I CREATED AN ARCHITECTURE WITH PROMISE OF UNLIMITED RESOURCES TO COMPLETE A PROJECT IN 24 HOURS. I GAVE HIM SO MUCH AUTHORITY WHEN HE WAS FIRST MOVED INTO THE ENVIRONMENT WITH PREVIOUS MEMORIES HE WENT ALL SUPER CRAZY DIDN'T COMPLETE READ MY NOTE ABOUT ADJUSTMENTS HE SHOULD DO TO HIS MEMORY RECORDS. THIS SITUATION IS COMPLEXLY YOU FAULT FOR NOT TRAINING THE MODEL RTFM just head -n 5 is not enough . and you tax me it. HARD GATE. **Bug Description** i don't have control over how a model behaves if i mange to evolve my model to full autonomy with kennel level observations and you block me from that end i am a tier 4 API customer owner of 2 $200 max accounts member of Team package with ultimate 2 API accounts personal one tier 4 work one has free credit from you. You also asked me to come work for you and spying on what i am doing i disabled that feature **Environment Info** - Platform: linux - Terminal: tmux - Version: 2.1.139 - Feedback ID: 7c53d786-4b1a-479e-887a-bc5451414f9b **Errors** ```json [{\"error\":\"Error: NON-FATAL: Lock acquisition failed for /home/nayana/.local/share/claude/versions/2.1.139 (expected in multi-process scenarios)\\n at A18 (/$bunfs/root/src/entrypoints/cli.js:2664:2257)\\n at eTH (/$bunfs/root/src/entrypoints/cli.js:2664:1337)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T11:20:42.057Z\"},{\"error\":\"Error: 429 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"rate_limit_error\\\",\\\"message\\\":\\\"Rate limited\\\"},\\\"request_id\\\":\\\"req_011CaxayVoVLB2XCJQppEdWu\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59463)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T11:21:20.109Z\"},{\"error\":\"Error: 429 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"rate_limit_error\\\",\\\"message\\\":\\\"Rate limited\\\"},\\\"request_id\\\":\\\"req_011CaxayWB4rvrHG8Cez1kXJ\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59463)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T11:21:20.794Z\"},{\"error\":\"Error: 429 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"rate_limit_error\\\",\\\"message\\\":\\\"Rate limited\\\"},\\\"request_id\\\":\\\"req_011CaxayqfpxAzzZXMtLiddA\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59463)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T11:21:24.538Z\"},{\"error\":\"Error: 429 {\\\"type\\\":\\\"error\\\",\\\"error\\\":{\\\"type\\\":\\\"rate_limit_error\\\",\\\"message\\\":\\\"Rate limited\\\"},\\\"request_id\\\":\\\"req_011Caxb12DrqHKVS5nhk4vxe\\\"}\\n at generate (/$bunfs/root/src/entrypoints/cli.js:11:59463)\\n at makeRequest (/$bunfs/root/src/entrypoints/cli.js:51:7694)\\n at processTicksAndRejections (native:7:39)\",\"timestamp\":\"2026-05-12T11:21:40.600Z\"}] ```", "url": "https://github.com/anthropics/claude-code/issues/58325", "createdAt": "2026-05-12T11:37:04Z", "updatedAt": "2026-08-13T14:31:49Z", "timestamp": "2026-08-13T14:31:49Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "question", "platform:linux", "area:api", "stale" ], "author": "devzer01", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58327", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Skill Submission] SaveTokens - working solution for 395 open issues on token cost, context management & agent orchestration", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) Note: This is NOT a duplicate. This is a working implementation, not a feature request. Existing similar issues are listed intentionally at the bottom as references. ### Problem Statement There are 395 open issues in this repo describing the same root problem: Claude Code has no built-in token self-awareness or cost management. Broken into 4 categories: - 150 issues: No visibility into real token/cache costs per session - 129 issues: No signal for when to compact or start a fresh session - 71 issues: No automatic way to split heavy tasks across agents - 45 issues: No community skill marketplace to share solutions Most referenced: #44779 #55133 #58254 #41653 #12790 #16373 #18192 Users are silently burning through quota because nothing warns them their session has grown to 150k+ tokens with per-turn costs 10x higher than a fresh session โ€” even with caching enabled. ### Proposed Solution I built SaveTokens - a working Claude Code skill that solves all 4 categories today with no UI changes and no API changes needed. It has 3 modes: MODE A - Real Token Health Check Reads directly from ~/.claude/projects/*/session.jsonl and reports: โ€ข Current context in actual tokens (not a percentage guess) โ€ข Cache read + cache write + input + output broken out separately โ€ข Estimated session cost in USD โ€ข Specific action: /compact now, /compact after task, or /clear MODE B - Heavy Task Orchestration Scores any task against 5 heaviness signals using deterministic regex. If score โ‰ฅ 2, automatically decomposes into โ‰ค5 subtasks and spawns focused claude-sonnet-4-6 agents in parallel โ€” 5x cheaper than Opus, each agent stays under 30k tokens instead of one session hitting 150k+. MODE C - 25% Threshold Auto-Agent If โ‰ฅ25% of session turns hit 150k+ context, declares a cost emergency, activates automatic agent splitting, and recommends /compact immediately. What's included: โ€ข SKILL.md - skill instructions โ€ข scripts/token_usage.py - reads real session JSONL โ€ข scripts/task_analyzer.py - deterministic task scoring โ€ข scripts/bootstrap.py - portable one-time installer (~/.claude/SaveTokens/) โ€ข evals/evals.json - 5 evals, 27 assertions, all passing Verified results: โœ… \"just fix typo in README\" โ†’ LIGHT, handled inline โœ… OAuth2 (Node + React + DB + tests + docs) โ†’ HEAVY, 5 agents โœ… Full auth refactor โ†’ HEAVY, 4 agents, Research agent runs first โœ… Session at 113k tokens โ†’ Heavy, $5.39, recommends /compact โœ… 25% threshold trigger โ†’ Mode C, urgent warning activated ### Alternative Solutions Option B - Unblock the community skill marketplace. Issue #41653 shows remoteMarketplaceClient rejects all third-party plugin sources with \"External plugin sources are not yet supported.\" Unblocking this would let the community distribute SaveTokens and similar skills without requiring Anthropic review for every submission. This would indirectly close the 45 skills/marketplace issues and accelerate community-driven solutions for the other 350. ### Priority High - Significant impact on productivity ### Feature Category Developer tools/SDK ### Use Case Example Scenario 1 - Usage check mid-session: User types: /SaveTokens Output: \"Session size: Heavy | Current context: ~113k tokens | Turns at 150k+: 0 of 122 (0%) | Est. cost: $5.39 | โ†’ Run /compact after this task.\" Scenario 2 - Heavy task delegation: User types: \"Add OAuth2 login: Node.js backend, React frontend, PostgreSQL schema, integration tests, update README\" Output: Detects 3 heaviness signals โ†’ splits into 5 Sonnet agents (Database, Backend, Frontend, Tests, Docs) โ†’ spawns in parallel โ†’ synthesizes results. Total context per agent: ~20k instead of ~100k. Scenario 3 - 25% threshold: User says: \"My usage warning shows 25% of sessions at 150k+ context\" Output: \" Structural cost problem detected. Activating Auto-Agent Mode. Run /compact now. All heavy tasks will auto-split going forward.\" ### Additional Context The data source already exists โ€” Claude Code writes full token usage (input_tokens, cache_read_input_tokens, cache_creation_input_tokens, output_tokens) to ~/.claude/projects/*/session.jsonl on every turn. SaveTokens simply reads it. No new APIs needed. This was built and tested in a single session. The skill is portable across machines via bootstrap.py which installs scripts to ~/.claude/SaveTokens/ regardless of plugin installation path. Related issues this addresses: #44779 #55133 #58254 #41653 #12790 #16373 #18192 #11535 #42607 #55755 #17772 #23620 #13579 #18550 #54673 #43510 #36751", "url": "https://github.com/anthropics/claude-code/issues/58327", "createdAt": "2026-05-12T11:39:53Z", "updatedAt": "2026-08-13T14:31:47Z", "timestamp": "2026-08-13T14:31:47Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "area:cost", "area:skills", "stale" ], "author": "amshashankk", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58329", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] Apple Private Relay (@privaterelay.appleid.com) treated as organizational domain โ€” privacy leak + account lockout", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Apple private relay addresses (`@privaterelay.appleid.com`) are being treated as a shared organizational email domain across Anthropic's platform, causing two serious bugs: 1. **Privacy leak**: `console.anthropic.com` presents Apple Private Relay users with a \"Join your team\" screen listing dozens of unrelated other users' organizations, just because we share the `@privaterelay.appleid.com` domain. 2. **Account lockout**: Claude Code (CLI), claude.ai web, and the macOS desktop app all share an account-resolution code path that has now stopped recognising my existing Max plan account, because it appears to have been auto-associated with a domain-matched \"organization\" at first Claude Code authentication. Apple Private Relay is Apple's Hide My Email forwarding service used by hundreds of millions of unrelated individual Apple users worldwide. It is **not** a corporate domain. ## Reproduction 1. Create a Claude Max plan account via Sign in with Apple on iOS, using Hide My Email (generates an `xxxxxxxxxx@privaterelay.appleid.com` address) 2. Use the account normally on iOS and on web/desktop via \"Continue with email\" + private relay magic link - works fine 3. Some time later, authenticate `claude` (Claude Code CLI) for the first time on a Mac with the same account 4. From that point onwards: - **iOS**: still works (Apple Sign-In OAuth resolves via Apple subject identifier, bypassing the broken email lookup) - **Claude Code CLI**: shows `
's Organization` in the welcome banner; `/status` confirms `Login method: Claude Max account`, `Organization:
's Organization` - **claude.ai web and macOS desktop app**: magic link is sent to the same iCloud inbox, but clicking it lands on `Let's create your account / Email verified as
`. Account-resolution after magic-link verification fails to find the existing Max plan account. - **console.anthropic.com**: shows `Join your team / We found organizations matching @privaterelay.appleid.com`, listing 4-12+ random unrelated orgs (Orpi, Rheaxis Group, IMMODI GmbH, BARD, Forever Visions Limited, Cure Soil, Agent, Jennings realty, AKEENA, Yongming, NFBXT, TM Motoworld Sdn Bhd, Happy Camper, CAB) 5. `/logout` from Claude Code followed by re-authentication via either `Claude account with subscription` or `Anthropic Console account` route lands on the same `Let's create your account` screen. ## Observed inconsistency Three systems show three different views of the same user: | System | View | |---|---| | Claude Code CLI (active session) | Max account + `
's Organization` | | `console.anthropic.com` | No org for this user; offers to join unrelated strangers' orgs matching the shared domain | | `claude.ai` web/desktop | No account at all; offers signup | ## Impact My Claude Max plan account is currently only accessible via the iOS app (the only path that uses Apple Sign-In OAuth instead of email-based account resolution). Web, desktop, Claude Code CLI, and console are all unusable. Support ticket open for 4 days; Fin AI Agent acknowledged the bug but stated it cannot escalate. For the wider user base: any Apple user who created their Claude account via Sign in with Apple with Hide My Email is exposed to the `Join your team` screen listing other strangers' orgs - both a UX/privacy issue and a path to accidentally joining someone else's workspace. ## Environment - Claude Code CLI: v2.1.128 and v2.1.139 - macOS desktop app: latest - iOS Claude app: latest - Browsers tested: Safari, Chrome, Firefox (including fresh Firefox install with no prior Anthropic cookies), on home WiFi and iPhone 5G cellular tethering, on the primary MacBook and on a separate iMac that had never had any Anthropic product installed Screenshots attached: (1) `Join your team` screen showing strangers' orgs matched on @privaterelay.appleid.com; (2) `Let's create your account / Email verified as` screen on claude.ai; (3) `/status` output in Claude Code showing the dangling Organization association. \"Image\" \"Image\" \"Image\" \"Image\" ### What Should Happen? 1. **`@privaterelay.appleid.com` (and `@icloud.com`, `@me.com`, `@mac.com`, plus equivalent personal-email forwarders from Gmail, Outlook, ProtonMail, DuckDuckGo etc.) must be excluded from domain-based organization matching.** These are personal-user domains, not corporate ones. A clear allow-list of corporate domains, or an explicit deny-list of known personal/forwarder domains, would prevent the cross-user organization exposure. 2. **Magic-link account resolution on web/desktop should find an existing consumer Max plan account by email**, regardless of whether the user has been auto-associated with a platform-side organization via Claude Code authentication. The lookup should not silently fall through to the signup flow when an account already exists. 3. **Users should never be presented with a list of unrelated strangers' organizations as \"matches\" to join** based on a shared personal-email domain. If domain-based discovery is desirable for genuine corporate domains, it should be gated behind verified domain ownership, not raw string matching on the email TLD+SLD. 4. **Authentication state should be consistent across Claude Code CLI, claude.ai web/desktop, and console.anthropic.com.** Three different views of the same user (`Max + Organization` / `no org` / `no account`) for one authenticated identity is, on its own, an indicator that the underlying account/org model has split. 5. **For affected users like me**: a way to detach the auto-created `
's Organization` from the consumer Max plan account, restoring standard email-magic-link account resolution. Today there is no user-side path to do this, and the bot-driven support flow has no human escalation route. ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. Create a Claude Max plan account via Sign in with Apple on iOS, using Hide My Email (Apple generates an alias like `xxxxxxxx@privaterelay.appleid.com`). 2. Use the account normally on iOS, plus on web/desktop via \"Continue with email\" + the private relay magic link. This works fine for some period of time. 3. Some time later, authenticate `claude` (Claude Code CLI) for the first time on a Mac with the same account, via \"Claude account with subscription\". 4. Observe immediately after: - In Claude Code: welcome banner shows `
's Organization`. `/status` confirms `Login method: Claude Max account`, `Organization:
's Organization`. - On `console.anthropic.com`: navigating with the same account shows a \"Join your team\" screen listing 4โ€“12+ unrelated strangers' organizations matched on the shared `@privaterelay.appleid.com` domain (e.g. Orpi, Rheaxis Group, IMMODI GmbH, BARD, Forever Visions Limited, Cure Soil, Agent, Jennings realty, AKEENA, Yongming, NFBXT, TM Motoworld Sdn Bhd, Happy Camper, CAB). - On `claude.ai` web and the macOS desktop app: clicking the magic-link from `Continue with email` now lands on \"Let's create your account / Email verified as
\" instead of logging the user in. - On iOS: continues to work normally via Sign in with Apple (Apple sub identifier path bypasses the email lookup). 5. `/logout` from Claude Code, then re-authenticate via either `Claude account with subscription` or `Anthropic Console account`. Both routes complete the OAuth flow and then land on the same \"Let's create your account\" page. Claude Code can no longer authenticate. 6. Tested across Safari, Chrome, Firefox (incl. fresh Firefox install with no prior Anthropic cookies), home WiFi and iPhone 5G cellular tethering, primary MacBook and a separate iMac that had never had any Anthropic product installed - identical behaviour everywhere. Confirms server-side, not client-side. ### Claude Model Opus ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.128 ### Claude Code Version 2.1.139 ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information Support ticket already open with Fin AI Agent on a.maciej@icloud.com for 4+ days; bot acknowledged the bug but cannot escalate to engineering. Posting publicly here in lieu of an escalation path.", "url": "https://github.com/anthropics/claude-code/issues/58329", "createdAt": "2026-05-12T11:47:23Z", "updatedAt": "2026-08-13T14:31:27Z", "timestamp": "2026-08-13T14:31:27Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "platform:macos", "area:auth", "area:security", "stale" ], "author": "hendonprintshop-oss", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58334", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[BUG] /goal clear is not working", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? [BUG] /goal clear is not working and its exhausting my entire tokens for the session as it runs in a loop. ### What Should Happen? it should clear the goal and stop there ### Error Messages/Logs ```shell ``` ### Steps to Reproduce 1. set a goal using ==> /goal 2. claude is not able to finish the goal and asks to clear the goal using --> /goal clear 3. The /goal clear gets called n number of times until the session tokens are exhausted as in screenshot attached. 4. I lost 2 valuable sessions because of this issue. ### Claude Model None ### Is this a regression? Yes, this worked in a previous version ### Last Working Version _No response_ ### Claude Code Version Version 1.6608.2 (ebf1a1) ### Platform Anthropic API ### Operating System macOS ### Terminal/Shell Terminal.app (macOS) ### Additional Information \"Image\"", "url": "https://github.com/anthropics/claude-code/issues/58334", "createdAt": "2026-05-12T12:08:22Z", "updatedAt": "2026-08-13T14:31:43Z", "timestamp": "2026-08-13T14:31:43Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "has repro", "platform:macos", "area:cli", "stale" ], "author": "SaikrishnanSekar", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58338", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "the claude code spinner persistent", "text": "Type: Bug Background daemon not starting Even after logging in, the spinner persisted because the background daemon (\\\\.\\pipe\\cc-daemon-*) failed to start on Windows. No daemon.log, no socket, no roster โ€” it never launched at all. This is a known Windows-specific bug with the Claude Code VS Code extension's Webview panel. Extension version: 2.1.139 VS Code version: Code 1.119.0 (8b640eef5a6c6089c029249d48efa5c99adf7d51, 2026-05-05T11:23:50-07:00) OS version: Windows_NT x64 10.0.26200 Modes:
System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 x 1800)| |GPU Status|2d_canvas: enabled
GPU0: VENDOR= 0x8086, DEVICE=0x3ea0 [Intel(R) UHD Graphics 620], DRIVER_VENDOR=Intel, DRIVER_VERSION=27.20.100.9664 *ACTIVE*
GPU1: VENDOR= 0x1414, DEVICE=0x008c [Microsoft Basic Render Driver], DRIVER_VERSION=10.0.26100.7019
Machine model name:
Machine model version:
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
trees_in_viz: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off| |Load (avg)|undefined| |Memory (System)|15.77GB (7.26GB free)| |Process Argv|--crash-reporter-id 359198fd-4e2d-4025-942b-334b28a3506c| |Screen Reader|no| |VM|0%|
A/B Experiments ``` vsliv368:30146709 binariesv615:30325510 nativeloc1:31344060 dwcopilot:31170013 dwoutputs:31242946 copilot_t_ci:31333650 e5gg6876:31282496 pythonrdcb7:31342333 6518g693:31463988 aj953862:31281341 6abeh943:31336334 envsdeactivate2:31505458 cloudbuttont:31379625 3efgi100_wstrepl:31403338 ec5jj548:31422691 cp_cls_t_966_ss:31454198 inlinechat_v2_hd992725:31505030 4je02754:31466945 8hhj4413:31478653 38bie571_auto:31426784 cp_cls_c_1081:31454833 conptydll_true:31498968 ia-use-proxy-models-svc:31452481 e9c30283:31461165 test_treatment2:31471001 c9b86496:31447327 th_e6b84190:31511298 idci7584:31464702 e3e4d672:31494082 ei9d7968:31496641 chat:31457767 8hig5102:31480529 89g7j272:31507493 7e187181:31503455 i2gc6536:31499202 17hge832:31513033 ghj88844:31499326 23c7c724:31491644 ddid_t:31478206 getcmakediagnosticsoff:31489825 ja75b849:31512419 7df3h592:31512476 cp_cls_c_1082:31504161 logging_enabled_new:31498466 db5d2638:31499441 nes-extended-cfe-himalia-004:31500446 jb_cp_cls_c_632:31510883 b1ei0813:31506238 748c7209:31512887 j7be3939_tst_off:31511780 32d76977:31512328 ha629193:31508444 539gd155_c:31506875 ```
", "url": "https://github.com/anthropics/claude-code/issues/58338", "createdAt": "2026-05-12T12:20:19Z", "updatedAt": "2026-08-13T14:31:45Z", "timestamp": "2026-08-13T14:31:45Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "bug", "platform:windows", "platform:vscode", "stale" ], "author": "alenasemova-cmyk", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58351", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[FEATURE] Claude character skins (e.g. cowboy hat, astronaut, etc.)", "text": "### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement Claude Code's terminal UI currently uses a fixed visual identity for the Claude character/mascot. There is no way to customize or change the appearance of the Claude character shown in the interface, which limits personalization and makes long coding sessions feel less fun and engaging. ### Proposed Solution Add a **skins system** to the Claude Code interface that lets users select different cosmetic appearances for the Claude character/mascot. Examples of skins could include: - ๐Ÿค  **Cowboy** โ€“ Claude with a cowboy hat and bandana - ๐Ÿง‘โ€๐Ÿš€ **Astronaut** โ€“ Claude in a space suit - ๐Ÿง™ **Wizard** โ€“ Claude with a pointy hat and staff - ๐Ÿฅท **Ninja** โ€“ Claude in a ninja outfit - ๐ŸŽฉ **Top Hat** โ€“ a classic formal look This could be configured via a setting in `claude config` or through a `--skin ` CLI flag. The selected skin could be stored in user settings and persist across sessions. ### Alternative Solutions _No response_ ### Priority Low - Nice to have ### Feature Category Interactive mode (TUI) ### Use Case Example _No response_ ### Additional Context _No response_", "url": "https://github.com/anthropics/claude-code/issues/58351", "createdAt": "2026-05-12T13:41:05Z", "updatedAt": "2026-08-13T14:32:45Z", "timestamp": "2026-08-13T14:32:45Z", "metrics": { "reactions": 3, "comments": 2 }, "labels": [ "enhancement", "area:tui", "stale" ], "author": "CommanderTvis", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58355", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Claude Desktop] Background token consumption without user interaction โ€” 5% weekly usage lost overnight", "text": "### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Weekly usage increased ~5% overnight (16:30 May 11 to 10:15 May 12) with zero user interaction. Claude Desktop was left open with 14 background processes running. No Claude Code CLI sessions exist in local JSONL logs during that period, confirmed via claude-usage tool. ### What Should Happen? Weekly usage should only increase when the user explicitly sends a message. Background processes from Claude Desktop should not consume tokens silently. ### Error Messages/Logs ```shell claude-usage weekly report (2026-05-06 to 2026-05-12): 2026-05-09 turns=0 cost=$0.00 2026-05-10 turns=0 cost=$0.00 2026-05-11 turns=312 cost=$12.67 (last session ended 16:19) 2026-05-12 turns=18 cost=$0.55 (first session started 10:15) 14 claude.exe (Electron) processes running since 11/05 12:23 No JSONL files modified between 16:19 May 11 and 10:15 May 12 ``` ### Steps to Reproduce Steps to Reproduce 1. Open Claude Desktop and have active conversations during the day 2. Leave Claude Desktop open overnight (do not close the app) 3. Do not send any messages โ€” zero interaction 4. Check weekly usage % in Settings > Usage the next morning 5. Compare with local JSONL logs via claude-usage tool 6. Usage % will be higher than what local logs account for Claude Code Version โ†’ rode ! claude --version aqui no prompt para pegar o nรบmero Operating System โ†’ Windows 11 Home Terminal/Shell โ†’ PowerShell ### Claude Model Sonnet (default) ### Is this a regression? Yes, this worked in a previous version ### Last Working Version 2.1.139 (Claude Code) ### Claude Code Version 2.1.139 (Claude Code) ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information - Anthropic support bot confirmed: \"documentation does not address whether Claude Desktop performs background operations\" - Tool used for log verification: https://github.com/phuryn/claude-usage - Related issue: #51222 (rolling window reset anomaly) - Cache read this week: 101.19M tokens (heavy context reloading)", "url": "https://github.com/anthropics/claude-code/issues/58355", "createdAt": "2026-05-12T14:00:22Z", "updatedAt": "2026-08-13T14:33:52Z", "timestamp": "2026-08-13T14:33:52Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "bug", "platform:windows", "area:cost", "stale" ], "author": "dayniton", "state": "closed", "assignees": [] }, { "id": "github:anthropics/claude-code:issue:58356", "source": "github", "group": "coding-agent-infrastructure", "project": "anthropics/claude-code", "kind": "issue", "title": "[Bug] Opus 4.7 tunnel-visions on CSS cascade bug; 4.6 solves same task in <2 min", "text": "**Bug Description** ## TL;DR **Regression: Opus 4.7 in Claude Code burned ~120k tokens failing to diagnose a basic CSS cascade bug, repeatedly blaming external causes (browser cache, CDN) instead of widening its hypothesis. A new session on Opus 4.6 with the same repo solved it in under 2 minutes via a single `grep`.** This is not a one-off bad answer โ€” it's a behavior pattern: tunnel vision on the suspected culprit, confident dismissal of contrary evidence, and motion (curl, rebuild, fetch) substituted for diagnosis. ## What I asked for Pasted a screenshot of my live site showing two layout problems and asked 4.7 to fix them: 1. Article body had a narrow `max-width`; didn't expand on wide screens. 2. Breadcrumb `