[Cowork] Scheduled task runs deny mcp__workspace__bash and mcp__workspace__web_fetch by permission rule since the Sept 2 desktop update (interactive tasks unaffected)

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 Desktop update on 2026-09-02 (bundled Claude Code 2.1.258), every locally-run scheduled task session in Cowork has the sandbox VM tools denied by a permission rule. Ordinary interactive Cowork tasks on the same machine, same permission mode, can still run mcp__workspace__bash normally (verified with echo ok). The same scheduled task ran 227 shell commands with zero denials a few hours before the update.

Every denial in the per-session audit.jsonl is a rule decision, not a prompt, hook, or classifier:

{"type":"system","subtype":"permission_denied","tool_name":"mcp__workspace__bash","decision_reason_type":"rule","message":"Permission to use mcp__workspace__bash has been denied."}
{"type":"user","message":{"role":"user","content":[{"type":"tool_result","content":"Permission to use mcp__workspace__bash has been denied.","is_error":true}]},"tool_result_meta":[{"non_execution_kind":"permission-rule"}]}

Same scheduled task (rbtec-incident-lead-scan), before vs after the update:

| Run start (UTC) | init.permissionMode | workspace bash calls | denied |
|---|---|---|---|
| 2026-09-02 10:36 | bypassPermissions | 227 | 0 |
| 2026-09-04 20:03 | bypassPermissions | 1 | 1 |
| 2026-09-04 20:07 | bypassPermissions | 1 | 1 |

Every other scheduled session after the update is denied 100%: 3/3, 2/2, 2/2 (incl. web_fetch), 2/2 (mode auto), 4/4, 1/1, 3/3, 10/10 (incl. 2x web_fetch, in both bypassPermissions and auto).

Denied commands include trivial probes, so command content is irrelevant: echo ok, echo probe; date -u, echo test.

mcp__workspace__web_fetch is denied by the same rule, so the whole workspace MCP server (the sandbox VM) is blocked, not just bash. The tools are still listed in the init event's tools array, so this is a call-time deny rule rather than the tool being removed.

Ruled out on my side: no permissions.deny in ~/.claude/settings.json; no C:\ProgramData\ClaudeCode\managed-settings.json; no HKLM/HKCU\SOFTWARE\Policies\ClaudeCode; personal (non-enterprise) org; the per-session Cowork config dir has no settings file at all; the sandbox VM is running normally (vm_bundles\claudevm.bundle\rootfs.vhdx actively written). Disabling all third-party plugins with hooks changed nothing. Nothing in any settings file or permission mode can override a deny rule, so this is not user-fixable.

What Should Happen?

Scheduled task runs should have the same sandbox access as interactive Cowork tasks (the Cowork docs say scheduled tasks have "access to the same capabilities as regular Cowork tasks"). If the sandbox is intentionally restricted for unattended local runs, that should be documented and surfaced in the UI rather than appearing as a bare "Permission to use mcp__workspace__bash has been denied" that the user cannot override in any settings file or permission mode.

Impact: unattended local scheduled tasks that need any code execution (xlsx updates, hashing, atomic JSON writes) now fail mid-run. The model reports "Shell/bash unavailable this session (permission denied)" and continues with degraded output.

Error Messages/Logs

From <session>\audit.jsonl (Cowork local-agent-mode-sessions), scheduled run, permissionMode bypassPermissions:

{"type":"system","subtype":"init","cwd":"C:\\Users\\<user>\\AppData\\Roaming\\Claude\\local-agent-mode-sessions\\<acct>\\<org>\\local_09c358d2-...\\outputs","model":"claude-opus-5","permissionMode":"bypassPermissions","claude_code_version":"2.1.258","tools":[...,"mcp__workspace__bash","mcp__workspace__web_fetch",...]}

{"type":"assistant","message":{"content":[{"type":"tool_use","name":"mcp__workspace__bash","input":{"command":"echo ok"}}]}}
{"type":"system","subtype":"permission_denied","tool_name":"mcp__workspace__bash","tool_use_id":"toolu_01Br9ogxbeai4K3qpv9B65w7","decision_reason_type":"rule","message":"Permission to use mcp__workspace__bash has been denied.","timestamp":"2026-09-04T06:08:16.815Z"}
{"type":"user","message":{"role":"user","content":[{"type":"tool_result","content":"Permission to use mcp__workspace__bash has been denied.","is_error":true,"tool_use_id":"toolu_01Br9ogxbeai4K3qpv9B65w7"}]},"tool_use_result":"Error: Permission to use mcp__workspace__bash has been denied.","tool_result_meta":[{"id":"toolu_01Br9ogxbeai4K3qpv9B65w7","non_execution_kind":"permission-rule"}]}

{"type":"assistant","message":{"content":[{"type":"tool_use","name":"mcp__workspace__web_fetch","input":{"url":"https://support.claude.com/en/articles/13364135-use-claude-cowork-safely"}}]}}
{"type":"user","message":{"role":"user","content":[{"type":"tool_result","content":"Permission to use mcp__workspace__web_fetch has been denied.","is_error":true}]},"tool_result_meta":[{"non_execution_kind":"permission-rule"}],"timestamp":"2026-09-04T20:12:19.909Z"}

Same task, run started 2026-09-02T10:36:57Z (before the update): 227 mcp__workspace__bash tool_use events, 0 permission_denied events.

Steps to Reproduce

1. Claude Desktop (Microsoft Store build) on Windows 11, updated on or after 2026-09-02 (bundled Claude Code 2.1.258 under %LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\claude-code-vm\2.1.258).
2. In Cowork, create a scheduled task that uses a connected local folder (so it runs locally rather than in the cloud), e.g. task file C:\Users\<user>\Documents\Claude\Scheduled\<task>\SKILL.md with a step like "run echo ok in the sandbox shell and report the output".
3. Set the permission mode to "Skip all approvals" (also reproduces in "Automatically approve").
4. Let the schedule fire, or open the task's session on the Scheduled page and type "run it now".
5. Observe: every mcp__workspace__bash (and mcp__workspace__web_fetch) call returns Permission to use mcp__workspace__bash has been denied. The session's audit.jsonl shows "subtype":"permission_denied","decision_reason_type":"rule" and "non_execution_kind":"permission-rule".
6. Control: start a new ordinary (non-scheduled) Cowork task on the same machine in the same mode and ask it to run echo ok in the sandbox. It succeeds.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Desktop build before the 2026-09-02 update (Claude Code bundle prior to 2.1.258); last confirmed working run 2026-09-02 10:36 UTC

Claude Code Version

2.1.258 (bundled in Claude Desktop 1.44121.1, Cowork local session)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

• Environment: Windows 11 build 26200.9168, Claude Desktop Microsoft Store package Claude_pzs8sxrjxfjjc, updaterLastSeenVersion 1.44121.1, model claude-opus-5 in the affected sessions, personal (non-enterprise) org.
• cowork-policy-limits-cache.json for the org only contains enforce_web_search_mcp_isolation: {allowed: false}; orgCliExecPolicies is {}.
• Related on the surface but different: #74324 and #46788 are about permission dialogs never appearing. This one is a rule decision where no dialog is expected (skip mode), and it is scoped to scheduled runs only.
• I have the full before/after audit.jsonl files and session state JSON for ten scheduled sessions and can share redacted copies on request.