[BUG] Cowork crashes on every session with "Scheduled tasks not initialized" (100% reproducible)

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?

Actual behavior

Any Cowork session — including a bare "Hi" with no attachments, tools, or scheduling involved — crashes immediately with Error: Scheduled tasks not initialized thrown from CoworkScheduledTasks.getAllScheduledTasks. This is 100% reproducible, has never worked on this machine, and is isolated to Cowork specifically (regular Claude Desktop chat mode works fine).

What Should Happen?

Cowork session starts normally and processes the message.

Error Messages/Logs

Error trace (captured via Claude launched from Terminal)

Error occurred in handler for '$eipc_message$_..._$_claude.web_$_CoworkScheduledTasks_$_getAllScheduledTasks': Error: Scheduled tasks not initialized
    at Object.getAllScheduledTasks (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-CMJVFTis.js:13:4032090)
    at Proxy.s (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-CMJVFTis.js:13:1937121)
    at async l (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-CMJVFTis.js:7:204773)
    at async Session.<anonymous> (node:electron/js2c/browser_init:2:118168)


Reproduced again after a full reinstall, on a **different build** (index.chunk-6ly5IEOz.js), with an identical error signature and call chain shape — only the byte offsets shifted, consistent with a recompiled build rather than a different bug:


Error occurred in handler for '$eipc_message$_..._$_claude.web_$_CoworkScheduledTasks_$_getAllScheduledTasks': Error: Scheduled tasks not initialized
    at Object.getAllScheduledTasks (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-6ly5IEOz.js:13:4132609)
    at Proxy.s (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-6ly5IEOz.js:13:1964140)
    at async l (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.chunk-6ly5IEOz.js:7:70897)
    at async Session.<anonymous> (node:electron/js2c/browser_init:2:123634)


A separate, likely-unrelated IPC warning also fires each time (no handler registered for a Bluetooth-related transport):

Error occurred in handler for '$eipc_message$_..._$_claude.buddy_$_BuddyBleTransport_$_reportState': Error: No handler registered for '...BuddyBleTransport_$_reportState'

Likely-related finding: `disclaimer` helper process crashing on every session bootstrap

Sentry breadcrumbs (scope_v3.json) show the /Applications/Claude.app/Contents/Helpers/disclaimer helper process spawning and immediately dying — five separate times in one session — each occurrence clustered right after Cowork's session-bootstrap network calls (cowork_sysprompt_map, policy_limits, plugins/enabled-state, memory, syncs, docs — all of which return 200 OK, so this is not a backend/network/auth issue):

{"category":"child_process","message":"Child process exited with code '143'","data":{"spawnfile":"/Applications/Claude.app/Contents/Helpers/disclaimer"}}
{"category":"child_process","message":"Child process exited with code '1'","data":{"spawnfile":"/Applications/Claude.app/Contents/Helpers/disclaimer"}}

This pattern repeats identically on every session bootstrap attempt in the trail. Given the timing (helper dies immediately after each Cowork re-bootstrap, right alongside the scheduler error), this looks like a plausible root cause rather than a coincidence.

Follow-up: ran the helper directly to inspect it —

$ cd "/Applications/Claude.app/Contents/Helpers/"
$ ./disclaimer
Usage: disclaimer [--pgroup | --ports-only] [--] <command> [args...]
exit code: 1

disclaimer is a wrapper/launcher, not a standalone service — it takes a <command> argument and (per its --ports-only/--pgroup flags) appears to declare sandboxing/port entitlements for whatever it launches, then execs it. This means the exit-code-1 entries in the breadcrumbs are not disclaimer itself crashing — they're consistent with disclaimer being invoked without a valid <command> argument (or with a target command that fails to resolve), which trips its own usage-error path.

If that read is right, the actual bug is one level deeper: something in Cowork's session-bootstrap is invoking disclaimer to launch a child process (plausibly the scheduler-init service, or a sandboxed agent/VM process), and that invocation is malformed or its target binary is missing/unresolvable on this machine — which would explain why the scheduler store is never created.

Steps to Reproduce

1. Open Claude Desktop
2. Start a new Cowork session
3. Send any message, e.g. "Hi"
4. App immediately shows "Claude Code crashed" banner

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude@1.49585.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_