[BUG] Cowork (Windows): mcp__workspace__bash denied in every session after updating to 1.44121.1.0 — worked on 1.40609.1.0

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?

After the desktop app auto-updated from Claude_1.40609.1.0 to Claude_1.44121.1.0 on
2026-09-02, the Cowork shell tool mcp__workspace__bash is denied in every session,
on a machine where it had been working daily.

Claude replies: "I don't have permission to run shell commands in this session.
Instead, I can read files from your folder directly using the Read tool."
The tool-level error is: Permission to use mcp__workspace__bash has been denied.

The Linux VM is healthy and the workspace MCP server connects normally with its
usual tools. The bash request never reaches the workspace MCP server at all: on every
day this worked, main.log contains [workspaceMcpServer] bash: lines; after the
update there is not a single one.

Execution counts from %LOCALAPPDATA%\Claude\Logs\main.log:

| Date | App version | [workspaceMcpServer] bash executions |
|------------|---------------|----------------------------------------|
| 2026-08-28 | 1.40609.0.0 | 50, all exit=0 |
| 2026-09-01 | 1.40609.1.0 | 12, all exit=0 (last at 17:11) |
| 2026-09-02 | update to 1.44121.1.0 around 11:40 | — |
| 2026-09-02 | 1.44121.1.0 | 0 — every attempt denied |

What I ruled out:

• Not the VM. It boots cleanly every time: `[VM:start] Startup complete, total time:

6279ms, [VM] Network status: CONNECTED, [VM] API reachability: REACHABLE`.
CoworkVMService Running from the current MSIX path; vmcompute and hvhost Running;
HyperVisorPresent True; 618 GB free disk.

• Not the workspace MCP server. It connects with its usual tools, identical to when it

worked: {"name": "workspace", "status": "connected", "toolCount": 2}. I compared this
in every session since 2026-08-28 and it is always 2, including on days bash worked.

• Not the approval flow. Also denied with the session in bypassPermissions

(LocalAgentModeSessions.setPermissionMode: mode=bypassPermissions).

• Not a missing folder. Denied with a folder connected and mounted.
• Not local configuration. No permissions.deny anywhere: user settings.json,

settings.local.json, project .claude/settings.json, and
C:\ProgramData\ClaudeCode\managed-settings.json (absent). No plugin PreToolUse hook
matching bash.

• Not org policy. Individual Max account, no organization. "Code execution" and

"network egress" are both enabled in account capabilities.

• Not stale app state. Full quit and relaunch, and new conversations, both reproduce it.

What Should Happen?

The shell command should run inside the isolated Linux VM and return its output, as it
did on app version 1.40609.1.0 — same machine, same account, same project, same
connected folder.

Error Messages/Logs

Permission to use mcp__workspace__bash has been denied

--- Last successful execution, on the previous app version (1.40609.1.0),
--- same project and same mounted folder that fails today:

2026-09-01 17:11:11 [info] [workspaceMcpServer] bash: vmStatus=ready after 0ms wait, cmdLen=533, vmCwd=/sessions/wizardly-busy-hopper/mnt/<folder>, mounts=<folder>,uploads,.claude/skills,.claude/projects,outputs,.remote-plugins/...
2026-09-01 17:11:14 [info] [workspaceMcpServer] bash done: exit=0, duration=2019ms, outputBytes=6

--- After updating to 1.44121.1.0: VM starts fine, but no bash line is ever logged.

2026-09-02 16:12:10 [info] [VM:start] Startup complete, total time: 6279ms
2026-09-02 16:12:10 [info] [VM] API reachability: REACHABLE
2026-09-02 16:21:18 [info] [LocalAgentModeSessionManager] mcpServerStatus returned 22 servers (13 with tools)
  { "name": "workspace", "status": "connected", "serverInfo": { "name": "workspace", "version": "1.0.0" }, "toolCount": 2 }
2026-09-02 16:31:45 [info] LocalAgentModeSessions.setPermissionMode: sessionId=local_<id>, mode=bypassPermissions
  -> still denied

--- Possibly related. This line does NOT exist in the previous build and appears on
--- every session spawn in 1.44121.1.0. 12 of 39 permission allow rules are not making
--- it onto the spawn argv:

2026-09-02 16:21:13 [info] [HostLoop] spawn argv ~1568 chars; 27 of 39 allow rules on argv

Steps to Reproduce

1. On Windows 11, with Claude desktop app version 1.44121.1.0 (MSIX), open a Cowork chat.
2. Connect a folder to the chat ("Add folder"). I used a folder that worked the day

before on version 1.40609.1.0.

1. Ask Claude to run any shell command, e.g. ls.
2. Claude answers: "I don't have permission to run shell commands in this session."

The tool error is Permission to use mcp__workspace__bash has been denied.

Reproduces 100% of the time. Also reproduces:

• in a brand new conversation
• after fully quitting and relaunching the app
• with the permission mode set to "Skip all approvals" (bypassPermissions)
• with and without a folder connected

Note: this is the Cowork tab of the desktop app, not the CLI. The same machine runs
shell commands normally in the Code tab, which uses the built-in Bash tool instead of
mcp__workspace__bash.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.40609.1.0 (Claude desktop app)

Claude Code Version

2.1.258 (Claude Code) — bundled with Claude desktop app 1.44121.1.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is the Cowork tab of the Claude desktop app on Windows, not a terminal session —
the Terminal/Shell field above has no accurate option for it.

Environment details:

• Windows 11 Home Single Language, build 10.0.26200.9168
• Claude desktop, MSIX package Claude_1.44121.1.0_x64__pzs8sxrjxfjjc
• No legacy / non-MSIX Claude install present on the machine
• Individual Max plan (no organization, so no admin tool policy involved)
• Cowork running locally (not in the cloud)
• claude-code SDK installed into the VM: 2.1.258 (was 2.1.255 while working)

Side note, possibly the same regression: "Automatically approve" is greyed out in the
permission mode selector on this Individual Max account, leaving only "Approve
manually" and "Skip all approvals".

Documentation note: the log directory moved from %APPDATA%\Claude\logs to
%LOCALAPPDATA%\Claude\Logs in this build. The old path still holds stale files, which
makes it look like logging stopped. Worth mentioning in troubleshooting docs.