### 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 Desktop (Cowork mode), Windows 11 Pro 10.0.26200 App version: Claude 1.44121.1 (0ec430), built 2026-09-02T02:45:14Z Model: claude-fable

[BUG] Cowork (Windows): mcpworkspacebash and web_fetch instantly denied in every session, no dialog — related to #57101 / #74324

Status Open

Maintainer reply None cached

Activity 3 comments · opened Sep 2, 2026

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?

Environment
Claude Desktop (Cowork mode), Windows 11 Pro 10.0.26200
App version: Claude 1.44121.1 (0ec430), built 2026-09-02T02:45:14Z
Model: claude-fable-5-1 (also reproduced on Sonnet)
Bug

Every Cowork session, mcp__workspace__bash and mcp__workspace__web_fetch return Permission to use mcp__workspace__bash has been denied. instantly. No approval dialog is shown. This is restart-proof and has persisted across ~10 sessions since 2026-09-02.

Every session's system notice says the session is "non-interactive," which appears to be what causes the harness to fabricate a denial before the sandbox is ever reached.

What works
Read / Write / Edit file tools
Claude in Chrome tools
Computer-use request_access — a dialog DID pop for Notepad, Allow was granted. So approval dialogs are not broken session-wide; only the workspace server is affected.
What has been ruled out
No settings*.json or .claude.json deny rules in either project folder or C:\Users\eric\.claude.
"Skip all approvals" mode ON: still denied (both same session and fresh session).
Help → Troubleshooting → Clear Cache and Restart: still denied.
Sandbox VM health (admin PowerShell):
CoworkVMService Running / Automatic; vmcompute Running; hns Running.
Application event log: zero events from Cowork / secureconnection providers in the last 200 entries — no crashes, no VHDX/HCS errors. The VM is never touched; the denial is emitted before any sandbox activity.

What Should Happen?

Expected

Either an approval dialog for bash, or bash executing (with skip-approvals on).

Actual

Immediate Permission to use mcp__workspace__bash has been denied. with no user interaction.

Error Messages/Logs

Steps to Reproduce

don't know

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

Claude 1.44121.1 (0ec430) 2026-09-02T02:45:14.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

#57101, #74324, #46788 — same signature (harness reports "user denied" without a prompt).

View original on GitHub ↗

3 Comments

ManuW-CNC · 9 hours ago

Same bug, same build, independent machine. Adding log evidence from cowork-service.log that pins the regression to the update itself:

Last working version: 1.40609.1.0 — last successful VM command at 2026-09-02 16:22:47 (exit[oneshot-…]: code=0).
16:48:56 service stopped for update; 16:49:00 restarted from Claude_1.44121.1.0_x64__pzs8sxrjxfjjc.
16:49:42 VM started successfully, 16:49:48 sdk-daemon is ready, 16:49:56 API reachability: REACHABLE.
After that: zero exit[oneshot-…] entries across 4 further clean VM restarts. The VM is healthy and idle; the denial is emitted before dispatch.

Env: Windows 11 Pro 25H2 build 26200.9168, Max plan, no org, no managed settings, ~/.claude/settings.json has only theme and agentPushNotifEnabled. Support ticket 215475761260422 (escalated to human support).

ManuW-CNC · 9 hours ago

Control data point: I have a second Windows machine on the same account, same Windows 11 Pro build, still on 1.40609.1 — Cowork bash works normally there right now. Same account, same OS, only the app version differs. That confirms 1.40609.1 as the last working version and isolates the regression to 1.44121.1.0.

WaitWut · 9 hours ago

Adding my own logs (original reporter). Same pattern as @ManuW-CNC on a second independent machine.

Log locations on Windows, for anyone else: C:\ProgramData\Claude\Logs\cowork-service.log (local time) and C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log (UTC).

Daemon log (coworkd, UTC): 35 successful oneshot-… dispatches this morning, last at 13:48:26 (= 09:48 local):

2026/09/02 13:48:26 [process:oneshot-9dd6bf68-…] started PID 10222
2026/09/02 13:48:26 [process:oneshot-9dd6bf68-…] direct child exited: code=0 signal=<nil>
2026/09/02 13:48:26 [process:oneshot-9dd6bf68-…] all processes exited, proceeding with cleanup

After that: zero started PID entries for the rest of the day, across ~10 Cowork sessions in which every mcp__workspace__bash / web_fetch call returned Permission to use … has been denied. instantly.

Service log (local time), after Help → Troubleshooting → Clear Cache and Restart at 13:55:

13:55:58 [VM] VM started successfully
13:56:00 [RPC] sdk-daemon connected from VM 26f0fef8-…
13:56:00 [VM] sdk-daemon is ready!
13:56:02 [RPC] API reachability: REACHABLE

Then continuous [Server] Client connected: user=eric exe=claude.exe / State":"Running" / Reusing existing session entries through 15:52 — the VM is up and the client keeps attaching, but nothing is ever sent to the daemon. No HCS errors, no VHDX errors, no crashes anywhere in either log.

So on both machines the denial is generated client-side before dispatch; the sandbox is healthy and idle. Skip-all-approvals mode has no effect. Service binary: C:\Program Files\WindowsApps\Claude_1.44121.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe.

[BUG] Cowork (Windows): mcp__workspace__bash and web_fetch instantly denied in every session, no dialog — related to #57101 / #74324