[BUG] Cowork create_scheduled_task hangs silently 180s on Windows - regression in v1.7196.0

## Summary

mcp__scheduled-tasks__create_scheduled_task (and the Cowork UI "Create scheduled task") times out after 180s on every attempt with MCP server "scheduled-tasks" tool "create_scheduled_task" timed out after 180s. list_scheduled_tasks works instantly. No task has ever persisted on this machine across 6+ days and ~12+ attempts. Restart, sign-out, OneDrive disable, and Documents-folder un-redirect did not help.

Evidence points to a regression in the Claude Desktop app version current as of v1.7196.0: the create code path now hangs upstream of the previously-logging API handler, producing zero log output during the 180s hang.

Reproducer

{
  "taskId": "erp-cowork-daily-hello",
  "description": "Send a \"Hello!\" message to the #erp-cowork Slack channel every Sunday-Thursday at 8:00 AM",
  "prompt": "Send a \"Hello! 👋\" message to the Slack channel #erp-cowork (channel ID: C0B3T8XKLEL) using the Slack connector.",
  "cronExpression": "0 8 * * 0-4",
  "notifyOnCompletion": false
}

Environment

• Claude Desktop 1.7196.0.0 (developer-signed MSIX, Claude_pzs8sxrjxfjjc)
• Windows 11 Pro 26200, no WSL
• Account: 2377f2b1-7af4-4b68-856e-6311b5289fdb, org 359ae1b9-79e2-4d5a-a6b4-c894a65a7705
• Network location: Egypt — network verified healthy (claude.ai TLS 0.6s, api.anthropic.com 0.27s)

Evidence of regression

• [CoworkScheduledTasksApi] createScheduledTask: name=<id> log line was emitted for create attempts on 2026-05-11 (x2: morning-brief, morning-greeting) and 2026-05-13 (x1: say-hello). Those also failed to persist, but at least reached the API entry point.
• After the app updated, this log line never fires again — confirmed via grep across the full 23,431-line main.log. The create call now hangs upstream of the previously-logging handler.
• During the 180s hang: zero log lines anywhere related to the call across main.log, cowork_vm_node.log, claude.ai-web.log, chrome-native-host.log. No file writes, no network calls, no VM activity, no errors, no sentry events.

Timeline of a single failed attempt (session local_79c53562-...)

01:27:01  Session started, cwd=/home/charming-pensive-davinci
01:27:02  Scheduled-tasks MCP server registered (16 servers with tools)
01:27:18  Permission request emitted: mcp__scheduled-tasks__create_scheduled_task
01:27:20  Permission approved (decision=once)
01:27:26  [MCP] tool_approval_gate warning fires in renderer (routine — fires on all MCP tool calls)
01:27:20 -> 01:30:32  ~~~ 192s of complete silence ~~~
01:30:32  Retry permission request emitted (180s MCP tool timeout fired)

At least 9 separate create_scheduled_task timeouts captured on May 17 alone (01:05, 01:07, 01:11, 01:21 x2, 01:23, 01:25, 01:26, 01:27).

Ruled out

• Write permission to ~/.claude/scheduled-tasks/ (direct write test succeeds)
• Network reachability to claude.ai / api.anthropic.com
• OneDrive / Cloud Files reparse points (Documents un-redirected, no change in behavior)
• Cowork VM health ([VM:start] Startup complete, total time: 6731ms, [VM] API reachability: REACHABLE)
• cowork-svc.exe (running in session 0, responding)
• Scheduled-tasks MCP server registration (toolCount: 3, status: connected)
• All other MCP tool calls work normally (web search, list_scheduled_tasks, Slack, etc.)
• Issue #22127 (UI-rendering hang) — different signature; tool actually completes there
• Issue #44032 (4-minute timeout on Windows) — different timeout, different signature
• Issue #56001 (UNC-redirected Documents) — fix did not help

Asks

1. Was the create_scheduled_task code path changed between app versions immediately preceding 1.7196.0? If so, what is the new entry-point logger that should appear (and may have been accidentally removed/silenced)?
2. Is there a way to surface the actual hang location — verbose MCP server logging, a tracing flag, or a debug build users in this state can opt into?
3. Workaround for affected users so they are not stuck without scheduled tasks.