[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](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?

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:

```json
{"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

```shell
From \audit.jsonl (Cowork local-agent-mode-sessions), scheduled run, permissionMode bypassPermissions:

{"type":"system","subtype":"init","cwd":"C:\\Users\\\\AppData\\Roaming\\Claude\\local-agent-mode-sessions\\\\\\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\\Documents\Claude\Scheduled\\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.

Start by comparing the affected scheduled-session audit.jsonl files with an ordinary interactive Cowork session, focusing on permission_denied rule decisions for mcp__workspace__bash and mcp__workspace__web_fetch. Then inspect the scheduled-session permission evaluation and the reported cowork-policy-limits-cache.json context in Claude Code 2.1.258. Done means scheduled sessions match interactive sandbox access, or an intentional restriction is clearly surfaced and documented.

Written by the indexing model from the issue text.