[BUG] Claude Desktop freezes on launch when scheduled-tasks.json exists in claude-code-sessions
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?
Description: Claude Desktop (v1.1.5368, macOS arm64) freezes on startup when a
scheduled-tasks.json file exists in ~/Library/Application
Support/Claude/claude-code-sessions/<account-id>/<org-id>/. The main process
pegs at 100% CPU and the UI becomes unresponsive.
Resolution: Removing scheduled-tasks.json from the claude-code-sessions
directory resolves the freeze immediately. All other session files load fine.
Environment: macOS 26.3.1, Apple M4 Pro, Claude Desktop 1.1.5368
What Should Happen?
Claude should open and run the scheduled task.
Error Messages/Logs
[CCDScheduledTasks] Spawning new session for scheduled task daily-blog-post
After that, the app just keeps resetting and reinitializing in a loop
(09:45:05 → 09:45:51 → 09:48:10 → 09:49:37). No explicit error — it spawns the
task, something goes wrong, resets, and loops forever.Steps to Reproduce
[CCDScheduledTasks] Spawning new session for scheduled task daily-blog-post
After that, the app just keeps resetting and reinitializing in a loop
(09:45:05 → 09:45:51 → 09:48:10 → 09:49:37). No explicit error — it spawns the
task, something goes wrong, resets, and loops forever.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.71
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
_No response_
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Removing the schedule tasks resolves this issue. I am using Claude desktop and had to troubleshoot with Claude terminal by removing all sessions and going one by one.
Similar issue but in the Cowork path. Claude Desktop 1.1.5368, macOS 26.4 (Tahoe), Apple M3 Pro.
In my case scheduled-tasks.json is in local-agent-mode-sessions (not claude-code-sessions). Same result: app freezes on launch at 100% CPU.
The trigger is specifically the filePath field on any task. A task without filePath loads fine. Adding filePath (even with enabled: false and coworkScheduledTasksEnabled: false in config) causes the freeze.
CPU sample shows the main thread blocked in uv__work_done → FileHandle::CloseReq::Resolve() → microtask/V8 loop. Appears the VM boot is happening synchronously on the main thread.
What I did to get it to work was to empty the scheduledTasks array before launching and then to recreate tasks again through the UI.
Thanks @brennanvitali-vwp and @Miandari. This solved it for me.
Thank you @Miandari - my scheduled-tasks.json is also in local-agent-mode-sessions (not claude-code-sessions).
Removing this file solved the problem. MacOS 15.7.4.
@Miandari - Can you confirm if the recreation of tasks via the UI still causes Claude to crash on restart, or if deleted the file and recreating permanently resolves the issue? Thanks.
Yeah, recreating the tasks through the UI solved the problem permanently.
Doesn’t that still recreate the schedule JSON? Or at that point does it not
matter.
Dithy Balaji
Seattle, WA
On Mon, Mar 9, 2026 at 2:04 PM Mostafa Miandari Hossein <
@.***> wrote:
The root cause was a Daylight Saving Time bug, not the file itself. Anthropic confirmed it on their status page: when the app tried to resolve tasks scheduled during the "skipped" DST hour it entered an infinite loop.
Recreating tasks through the UI works because the new tasks get fresh timestamps that don't fall in the skipped hour. The old scheduled-tasks.json had lastRunAt / cron times that landed in the DST gap.
The actual fix is updating to version 1.1.5749 that patches the DST handling so the original file would work too.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.