[BUG] Cowork local sessions: all mcp__workspace__* tools denied without any prompt after SDK 2.1.258 (Windows)
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?
Since the Claude Code SDK inside the Cowork VM was auto-updated to 2.1.258 (installed 2026-09-02 11:29 local time, per cowork_vm_node.log), every local Cowork session on this machine denies the workspace tools immediately, with no permission dialog. It worked normally earlier the same morning, before the SDK update was installed.
This happens in every existing local session and in new ones, in both Manual ("ask before acting") and Auto permission modes. All other MCP connectors (ClickUp, Fathom, Gmail, Google Drive, Claude in Chrome) keep working in the same sessions. Cloud Cowork sessions with the native shell work normally.
Already checked: no deny rules in any settings.local.json or .claude.json under local-agent-mode-sessions; claude_desktop_config.json has no relevant entry; the "workspace" server is not listed among connectors (it is internal); fully quitting and reopening the app and rebooting did not help. The VM itself starts fine ("VM already connected", SDK 2.1.258 installed on each start). The symptom pattern matches #74324 and #46788.
What Should Happen?
mcp__workspace__bash and mcp__workspace__web_fetch should run (Auto mode) or show a permission prompt (Manual mode), as they did before the update.
Error Messages/Logs
Permission to use mcp__workspace__bash has been denied.
Permission to use mcp__workspace__web_fetch has been denied.
cowork_vm_node.log:
2026-09-02 14:49:53 [info] [startVM] VM already connected
2026-09-02 14:49:53 [info] [postConnect] Installing SDK: subpath=c/Users/.../Roaming/Claude/claude-code-vm, version=2.1.258Steps to Reproduce
Windows 11, Claude desktop app, Cowork with a local session ("Only on this computer").
Let the app install SDK 2.1.258 into the Cowork VM (happened automatically on 2026-09-02).
In any local session, in Auto or Manual mode, ask Claude to run a trivial shell command such as echo ok.
The tool call fails immediately with "Permission to use mcp__workspace__bash has been denied." and no permission dialog is shown. Same for mcp__workspace__web_fetch with any URL.
Claude Model: Opus 5 (also reproduced with other models)
Is this a regression?: Yes
Last Working Version: The SDK version installed before 2.1.258 (the previous folder was replaced on update, so the exact number is not visible; 2.1.256 or earlier).
Claude Code Version: 2.1.258 (installed by the Cowork VM; taken from cowork_vm_node.log and the .sdk-version file)
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Previous SDK version auto-installed before 2.1.258 (exact number not visible, the folder was replaced on update; 2.1.256 or earlier). Worked on 2026-09-02 morning, before the 11:29 update.
Claude Code Version
2.1.258 (Claude Code SDK inside the Cowork VM, per cowork_vm_node.log and .sdk-version; no terminal claude install)
Platform
Other
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Environment: Windows 11, Claude desktop app (MSIX install), Cowork local session mode. Cloud sessions on the same account and machine are unaffected. Impact: all local Cowork sessions are unusable for shell, file processing and web fetch; existing project sessions cannot be continued. Screenshot of the denial with Auto mode visible attached.
3 Comments
Confirmed on a second machine, same signature.
Environment: Windows 11, Claude Desktop (MSIX), Cowork local session, model claude-fable-5-1 (also Opus). Started 2 Sep 2026.
Symptom:
Permission to use mcp__workspace__bash has been denied.and...mcp__workspace__web_fetch has been denied.instantly, no dialog, every session, both permission modes.Ruled out: no
settings.jsonexisted; created~/.claude/settings.jsonwith"allow": ["mcp__workspace__bash","mcp__workspace__web_fetch","mcp__workspace__*"], no change.remote-settings.jsonis{}. Full app quit/relaunch and full PC reboot, no change. Read/Write/Edit, connector MCPs, Claude in Chrome and computer-use all work in the same sessions.A second PC on the same account is still working, presumably on the pre-2.1.258 SDK, which supports the regression theory in the OP.
Impact: ~20 scheduled Cowork tasks that rely on bash (Python report builds, Playwright exports) are dead until this is fixed. This is a production-blocking regression, not a permission misconfiguration; please prioritise.
I have this behavior in Claude Desktop Version 1.44121.1 (0ec430)
Windows 11, Claude Desktop
Root cause and resolution observed on our machine (Windows 11, MSIX):
Timeline: last successful bash Sep 2 23:05 JST → desktop auto-update 1.40609.1 → 1.44121.1 (bundled CLI/SDK 2.1.258) at 23:38 → first denial 23:42. 33 denials, 0 successes across 13 sessions until the app auto-updated to 1.44121.4 (Sep 3 13:23 JST) — after which bash and web_fetch work again in both new and previously-affected sessions. No local settings were changed.
Mechanism (from audit logs + app.asar/CLI inspection): the host disables the built-in Bash/WebFetch tools in Cowork via
disallowedTools, while also passingtoolAliases {Bash → mcp__workspace__bash, WebFetch → mcp__workspace__web_fetch}. CLI 2.1.258's rule matcher expands deny rules naming Bash/WebFetch onto the aliased Cowork tools, so the host's own disable list blocks its own sandbox tools.audit.jsonlshowsdecision_reason_type: "rule", denial in ~17ms, and the workspace MCP server is never reached. No deny rules exist in any local settings/cache (all verified) — nothing to fix locally.If you're still affected: check whether your desktop app has updated to 1.44121.4 (ours did automatically). The VM/SDK version stays 2.1.258; the fix appears to be on the host side.