Cowork: mcp__workspace__bash and web_fetch denied in all sessions after desktop 1.44121.1 update (Windows)

Summary

After the desktop app auto-updated from 1.40609.1 → 1.44121.1 (bundled Claude Code 2.1.255 → 2.1.258), the two tools served by the Cowork workspace MCP server — mcp__workspace__bash and mcp__workspace__web_fetch — are denied in every Cowork session on this machine.

Every call returns immediately with:

Permission to use mcp__workspace__bash has been denied.

No permission prompt is ever shown. Every other tool (Read, Glob, Grep, WebSearch, remote MCP connectors) works normally.

The shell worked all day before the update and has not worked once since.

Environment

• Windows 11 Pro 10.0.26200 (x64)
• Claude desktop 1.44121.1, MSIX / Microsoft Store install (previously 1.40609.1)
• Bundled Claude Code 2.1.258 (previously 2.1.255)
• Cowork session type: hostLoopMode: true
• Connected workspace folder is a cloud-synced directory (resolvedFolderKinds: [{kind: "cloud-sync"}])

Reproduction / evidence

The strongest evidence is a single long-lived Cowork session that spanned the update (local_6c98ed71-80da-4746-9746-df629a8262a0). Same session, same connected folder, same settings, same permission mode. Timestamps below converted from the transcript's UTC to local (UTC+2):

15:22:35  mcp__workspace__bash -> ok
15:31:24  mcp__workspace__bash -> ok
15:40:29  mcp__workspace__bash -> ok
15:45:15  mcp__workspace__bash -> ok        <-- last success, app 1.40609.1

--- 16:12-16:13  silent background update to 1.44121.1 ---

16:47:56  mcp__workspace__bash -> "Permission to use mcp__workspace__bash has been denied."
16:59:24  mcp__workspace__bash -> denied
17:12:27  mcp__workspace__bash -> denied
18:28:38  mcp__workspace__bash -> denied
19:09:29  mcp__workspace__bash -> denied

The update itself, from %LOCALAPPDATA%\Claude\Logs\main.log:

16:01:31 [updater] Checking for updates
16:01:31 [updater] Found an update, downloading
16:02:11 [updater] Update downloaded and ready to install { releaseName: 'Claude 1.44121.1' }
16:12:41 [stealth-update] Triggering stealth update after idle timeout
16:12:42 beforeQuitForUpdate handler fired, going down for update
16:13:24 [CCD] Initialized with version 2.1.258
16:13:25 [updater] Version changed since last launch: 1.40609.1 -> 1.44121.1

Matching host-side log lines. [workspaceMcpServer] logs every dispatch; the last entry on this machine is the 15:45 success, and there has been no entry since — so the denial happens in the CLI before the MCP call is dispatched:

15:45:15 [workspaceMcpServer] bash: vmStatus=ready after 1ms wait, cmdLen=214, vmCwd=/sessions/<name>/mnt/<folder>
15:45:16 [workspaceMcpServer] bash done: exit=0, duration=1000ms, outputBytes=7
(nothing after this)

The VM itself is healthy and reachable throughout:

[VM:start] Startup complete, total time: 16546ms
[VM] API reachability: REACHABLE

Not a permission-mode issue

A freshly created post-update session running with permissionMode: "auto" is denied identically:

[23] TOOL_USE    mcp__workspace__bash :: python3 <script>
[24] TOOL_RESULT is_error=True :: "Permission to use mcp__workspace__bash has been denied."

Denials also occur under auto at 16:47, 16:59, 17:12 and 18:28 — i.e. before the session's permission mode was ever changed. Mode makes no difference.

Also ruled out

• No deny rules anywhere. ~/.claude/settings.json has no permissions block at all. The project settings.local.json has only allow entries.
• Adding explicit allow entries does not help. Adding mcp__workspace__bash and mcp__workspace__web_fetch to a project settings.local.json changed nothing — which is expected, since Cowork spawns the CLI with a session-private CLAUDE_CONFIG_DIR and cwd set to the session's outputs folder, so a project settings file in the connected folder is not on the settings path. Noting it only to document that it was tried.
• No managed settings / MDM policy. No managed-settings.json under %ProgramData% (checked ClaudeCode\, Claude\, Anthropic\ClaudeCode\), and no Policies\Anthropic or Anthropic keys under HKLM or HKCU. Checked because 1.44121.1's changelog mentions disableSideloadFlags affecting on-device Claude Code sessions and dropping sideloaded config — the mechanism would fit, but the policy is not set here.
• Org policy payload unchanged. orgCliExecPolicies reads {"status": "ok", "policies": {}} in every session record, identical before and after the update. The local CLI-ops gate file has not been modified since a week before the update.
• No permission prompt is ever emitted. Across four days of logs, the app has emitted Emitted tool permission request for many tools (remote MCP connectors, AskUserQuestion, Artifact, request_cowork_directory) but never once for mcp__workspace__bash. So there is no dialog being missed or auto-dismissed.
• Restarting the app, and starting brand-new sessions, make no difference.

Possible lead

The two affected tools are exactly the two the workspace MCP server provides, and the 1.44121.1 changelog includes:

Changed what happens when web fetch isn't available for your organization: Claude now says so instead of retrying and reporting failed fetches.

That suggests the org-availability gating for these workspace tools was reworked in this release. Since the underlying policy payload is byte-identical before and after, the change would be in how it is evaluated rather than in the data. Speculative — offered as a starting point, not a diagnosis.

Impact

• No shell in Cowork at all: cannot run scripts, cannot read or write .xlsx/.xlsm/.docx (the Read tool refuses binary files, so the shell was the only path).
• mcp__workspace__web_fetch is dead the same way.
• Scheduled tasks that shell out fail. A scheduled ingest task on this machine failed on exactly this denial.

Expected

mcp__workspace__bash and mcp__workspace__web_fetch remain usable in Cowork sessions after the update, as they were in 1.40609.1 — or, if a session genuinely lacks the grant, a permission prompt is shown rather than an unconditional deny with no way to approve it.