Fix: Claude Desktop Freezes on Startup (Cowork Scheduled Task Bug)

Claude Desktop freezes on startup after configuring scheduled tasks in Cowork. The catch-up mechanism for missed runs, combined with a high-frequency cron schedule, creates a persistent startup freeze that VM resets and cache clearing cannot fix. The solution is renaming scheduled-tasks.json.

This issue has been confirmed on both Windows and macOS (#32213, #32167, #32125). As of March 8, 2026, all three issues are open with no official fix.

The Fix

If Claude Desktop freezes on startup after configuring scheduled tasks:

Windows (PowerShell):

1. Kill all Claude processes:

   taskkill /F /IM "Claude.exe" 2>$null
   taskkill /F /IM "cowork-svc.exe" 2>$null

2. Find the scheduled task config:

   Get-ChildItem "$env:APPDATA\Claude" -Recurse -Filter "*schedul*"

3. Rename every match (if multiple files are found, rename all of them):

   Rename-Item "<path-to-scheduled-tasks.json>" "scheduled-tasks.json.bak"

4. Launch Claude Desktop. It should boot normally.
5. Recreate scheduled tasks with a less aggressive cadence; see scheduling guidance below.

macOS (Terminal):

1. Kill all Claude processes:

   killall "Claude" 2>/dev/null

2. Find the scheduled task config:

   find ~/Library/Application\ Support/Claude -name "*schedul*" 2>/dev/null

3. Rename every match:

   mv "<path-to-scheduled-tasks.json>" "<path-to-scheduled-tasks.json>.bak"

4. Launch Claude Desktop.

The .bak file preserves the original configuration for reference when recreating tasks. Renaming the file does not delete run history or skill file associations; those live in separate session files.

Root Cause

Claude Desktop’s scheduled task system includes a catch-up mechanism. From the official documentation:

When the app starts or your computer wakes, Desktop checks whether each task missed any runs in the last seven days. If it did, Desktop starts exactly one catch-up run for the most recently missed time and discards anything older.

In this case, two scheduled tasks were configured:

1. pinterest-evening-post: 6 PM, Sunday through Wednesday (0 18 * * 0,1,2,3)
2. shopforge-manager: 10 runs per day at hours 21, 22, 23, 0, 1, 2, 3, 4, 5, 6 (0 21,22,23,0,1,2,3,4,5,6 * * *)

At that frequency, there is almost always a missed run to catch up on. On every startup, the app:

1. Read scheduled-tasks.json
2. Detected missed runs (guaranteed with hourly scheduling)
3. Attempted to fire a catch-up session
4. Froze before the UI rendered

This created a persistent startup freeze. The VM was healthy, but the app could not get past catch-up initialization. Standard recovery steps (cache clearing, VM rebuilds, service restarts) do not touch the scheduled task configuration, so they cannot resolve it.

Why Standard Recovery Fails

The standard Cowork recovery steps for Windows are documented across GitHub issues (#25663, #26646, #26921):

Diagnosis Walkthrough

This section documents the full investigation for reference. The fix above is self-contained; this is not required reading.

Step 1: VM Reset (Ineffective)

From an elevated PowerShell:

taskkill /F /IM "Claude.exe" 2>$null
taskkill /F /IM "cowork-svc.exe" 2>$null

# If CoworkVMService refuses to stop gracefully, kill by PID
Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" | Select-Object Name, ProcessId, State
Stop-Process -Id <PID_FROM_ABOVE> -Force  # Replace with the ProcessId from the previous command

Remove-Item -Path "$env:APPDATA\Claude\claude-code-vm" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "$env:APPDATA\Claude\vm_bundles" -Recurse -Force -ErrorAction SilentlyContinue

VM rebuilt cleanly on relaunch. Freeze persisted.

Step 2: Clean State Verification (Ineffective)

# Disable auto-start by removing the exact registry entry
# First, inspect what entries exist:
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" |
  ForEach-Object { $_.PSObject.Properties } |
  Where-Object { $_.Name -like "*claude*" -or $_.Name -like "*Claude*" } |
  Select-Object Name, Value

# Then remove by exact name:
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "Claude" -ErrorAction SilentlyContinue

# Verify cache directories are gone
Test-Path "$env:APPDATA\Claude\claude-code-vm"   # Should be False
Test-Path "$env:APPDATA\Claude\vm_bundles"        # Should be False

After reboot, both returned False, confirming clean VM state. Freeze persisted.

Step 3: Locate the Scheduled Task Configuration

If the VM is clean but the app still freezes, something outside the VM is being read on startup.

taskkill /F /IM "Claude.exe" 2>$null
Get-ChildItem "$env:APPDATA\Claude" -Recurse -Filter "*schedul*" -ErrorAction SilentlyContinue

This located:

C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\
  <session-uuid>\<task-uuid>\scheduled-tasks.json

Note: this directory structure (<session-uuid>\<task-uuid>) is specific to scheduled task configuration. It differs from Cowork session files, which use {org-id}\{user-id}\local_{session-id}.json as documented in Reverse-Engineering Claude Desktop’s Cowork Session Format.

Contents:

{
  "scheduledTasks": [
    {
      "id": "pinterest-evening-post",
      "cronExpression": "0 18 * * 0,1,2,3",
      "enabled": true,
      "filePath": "C:\\Users\\<user>\\OneDrive\\Documents\\Claude\\Scheduled\\pinterest-evening-post\\SKILL.md",
      "createdAt": 1772584506788,
      "lastRunAt": "2026-03-05T02:00:29.120Z",
      "userSelectedFolders": ["C:\\Users\\<user>\\Projects\\ShopForge"]
    },
    {
      "id": "shopforge-manager",
      "cronExpression": "0 21,22,23,0,1,2,3,4,5,6 * * *",
      "enabled": true,
      "filePath": "C:\\Users\\<user>\\OneDrive\\Documents\\Claude\\Scheduled\\shopforge-manager\\SKILL.md",
      "createdAt": 1772962332070,
      "userSelectedFolders": ["C:\\Users\\<user>\\Projects\\ShopForge"]
    }
  ]
}

The shopforge-manager cron expression (10 runs per day) pointed to the cause. Note that shopforge-manager has no lastRunAt field, indicating it never successfully completed a run. Renaming this file resolved the freeze.

Notes

Scope of This Fix

The scheduled-tasks.json file and the local-agent-mode-sessions directory are Cowork-specific. This fix does not affect:

• Claude Code CLI sessions or configuration (~/.claude/)
• Claude Desktop chat history
• Claude Desktop settings or extensions
• The Cowork VM itself

If active Claude Code Desktop tab sessions were running when Claude.exe was force-killed, those sessions will report exit code 4294967295 (0xFFFFFFFF, unsigned -1). This is expected and does not indicate data loss. Sessions should be resumable after relaunch.

CoworkVMService May Resist Stopping

Restart-Service CoworkVMService -Force may fail with “cannot be stopped.” Kill the process directly by PID:

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" | Select-Object Name, ProcessId, State
Stop-Process -Id <ProcessId> -Force  # Replace with the ProcessId from the previous command

vm_bundles May Recreate on Boot

If Claude Desktop auto-launches on boot (default on Windows), the vm_bundles directory recreates before manual intervention is possible. Disable auto-start first, or kill the process immediately after boot.

Scheduling Cadence

The catch-up mechanism checks the last 7 days of missed runs. Any missed run triggers a catch-up attempt on next launch. Guidance based on observed behavior:

• Daily or less frequent (0 21 * * *): low risk. Catch-up fires at most once per launch.
• Every few hours (0 */4 * * *): moderate risk. May trigger catch-up reliably if the machine sleeps overnight.
• Hourly or more frequent (0 * * * *): high risk. Near-guaranteed catch-up on every launch. Avoid unless the app is kept running continuously.

When recreating tasks, consider whether high-frequency execution is necessary. The catch-up mechanism runs at most one catch-up per task per launch, but the initialization process itself appears to be the bottleneck.

Related GitHub Issues

Recommendations for Anthropic

1. Defer scheduling until after UI render. If catch-up initialization hangs, users have no recovery path through the UI.
2. Add a timeout to catch-up initialization. If the catch-up run does not complete within a reasonable window, skip it and surface the failure.
3. Expose scheduled task config in UI settings. Currently, the only way to remove a problematic task when the app cannot boot is to locate and edit the JSON file on disk.
4. Validate cron expressions against catch-up behavior. A task running 10+ times per day creates a near-guaranteed catch-up trigger on every launch.

Environment

• OS: Windows 11 Pro
• Claude Desktop: v2.1.71
• Subscription: Paid plan (Pro/Max)