[BUG] Cowork (Windows) scheduled task created from a pre-migration session is stamped with a frozen `spaceId` and can never launch — `space_migration_frozen` is swallowed and shown as "Failed to run task" / "Skipped" (machine asleep)

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?

A local Cowork scheduled task has never been able to launch — not manually, not on schedule. The
UI gives two different, misleading explanations for one underlying error that it never shows:

• Run now → toast: "Failed to run task. You can try again." Every time. Nothing is logged.
• Scheduled fire → History shows "Skipped", with the UI implying the computer was off or

asleep. It was awake and in use; another scheduled task ran by hand six minutes later.
The real error exists only in the renderer log:

2026-09-19 06:36:04 [error] [DESKTOP_API] Failed to start scheduled task session
{"scheduledTaskId":"apify-discovery","error":{"name":"Error","message":"space_migration_frozen", ...}}

Cause. My Cowork Space was migrated to a Project (~2026-09-15). In scheduled-tasks.json,
every task that was migrated — and still runs — looks like this:

```json
"migratedFromSpaceId": "<space-uuid>",
"userSelectedProjectUuids": ["<project-uuid>"]

The broken task alone looks like this — a LIVE pointer to the frozen Space, no project UUID:

```json
"spaceId": "<same-space-uuid>",
"notifySessionId": "local_<pre-migration-session>"

It was created on 2026-09-17, after the migration, by the create_scheduled_task tool inside a
long-running Cowork session that predates the migration. That path still stamps the old spaceId
onto new records. The task is dead on arrival.

Blocking new sessions in a migrated Space is presumably intentional. The bugs are everything
around that guard:

1. Creation still accepts and writes a frozen spaceId. create_scheduled_task from a

pre-migration session produces a task that can never run. No warning at creation.

1. Delete + recreate reproduces it. I deleted the task and recreated it (identical prompt,

identical cron) from the same session, on the newest desktop build. New record, same spaceId,
same failure. Nothing tells you the creating session is the variable.

1. The error is swallowed and replaced with wrong explanations. "Failed to run task" carries no

cause; "Skipped" blames machine availability. The main.log side is clean, so even log-reading
users look in the wrong place.

1. The scheduled occurrence is consumed. nextRunAt advances a full week although no session

was ever created (same surface symptom as #80671).

1. The task detail page hides the bad binding. It displays "Project: <my project>" and lists

folders "(from project …)" — the UI resolves the dead space ID for display, while the launch
path rejects it.

1. Manual "Run now" failures are not logged anywhere I could find (neither main.log nor

claude.ai-web.log), only toasted.

What Should Happen?

• Task creation from a session in a migrated/frozen Space should bind the new task to the successor

Project (the same rewrite the migration applied to existing tasks), or refuse with a clear message.

• The migration (or app start) should sweep for records that still carry a live spaceId for a

frozen Space and convert them.

• When a launch is rejected, show the actual reason in the toast and in task History — not

"Skipped", and not an implication that the computer was asleep.

• Don't consume the scheduled occurrence / advance nextRunAt when no session was created.
• Log "Run now" failures.

Error Messages/Logs

`%LOCALAPPDATA%\Claude\Logs\main.log` — dispatch succeeds, then silence:
 

06:35:03 [ScheduledTasks] Delaying dispatch for apify-discovery by 61s (jitter)
06:36:04 [ScheduledTasks] Spawning new session for scheduled task apify-discovery { cronExpression: '35 6 * * 6', fireAt: undefined, lastRunAt: undefined, missed: undefined, retry: undefined }
06:36:04 [ScheduledTasks] Dispatch acknowledged by renderer: apify-discovery
06:50:03 [warn] [ScheduledTasks] Cleared stale pending dispatch for: apify-discovery

 
`%LOCALAPPDATA%\Claude\Logs\claude.ai-web.log` — the only place the cause appears:
 

06:36:04 [error] [DESKTOP_API] Failed to start scheduled task session {"scheduledTaskId":"apify-discovery","error":{"name":"Error","message":"space_migration_frozen","stack":"Error: space_migration_frozen\n    at Od (…/shared-common-mcp-msg-4-7gKlRbN0.js:2:13647)\n    at …/shared-4-3uNoKwFw.js:15:4685\n    at Kq (…/shared-12-JPyJz6My.js:12:32693)\n    at async …/shared-15-BdTDy6Np.js:7:171415"}}

 
For contrast, a healthy (migrated) task in the same app session, 08:07 the same morning:
 

08:07:41 [ScheduledTasks] Spawning new session for scheduled task registry-maintenance {…}
08:07:42 [ScheduledTasks] Dispatch acknowledged by renderer: registry-maintenance
08:07:42 LocalAgentModeSessions.start:
08:07:42 [ScheduledTasks] Confirmed task run for: registry-maintenance

 
The broken task never reaches `LocalAgentModeSessions.start` / `Confirmed task run`.

Steps to Reproduce

I can't re-trigger a Space migration, so this is the observed sequence rather than a from-scratch reproduction:

1. Have a Cowork Space with a long-running session and working scheduled tasks.
2. Space is migrated to a Project. Existing tasks are rewritten to migratedFromSpaceId +

userSelectedProjectUuids and keep working.

1. In the same pre-migration session, ask Claude to create a new scheduled task

(create_scheduled_task).

1. Inspect scheduled-tasks.json: the new record has "spaceId": "<frozen space>" and no

userSelectedProjectUuids.

1. Click Run now → "Failed to run task. You can try again."
2. Wait for the cron time → History shows "Skipped"; claude.ai-web.log shows

space_migration_frozen.

1. Delete the task and recreate it from the same session → identical record shape, identical failure.

Workaround that worked: delete the task and recreate it by hand through the redesigned
Scheduled UI. That creates a server-side routine (trig_…, device-bound, folder grant in
claude_desktop_config.json → preferences.routineFolderGrants) instead of a local record, and
"Run now" launched immediately. Note this changes the type of task, so it sidesteps the bad
binding rather than proving a corrected local record would run.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Never worked for this task. Other (migrated) tasks work on 2.2553.1.

Claude Code Version

Claude Desktop 2.2553.1.0 (MSIX, Claude_pzs8sxrjxfjjc), previously 2.110.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

-Related, not duplicates: #80671 (lastRunAt/occurrence advances with no session — same
symptom, no cause identified; this may be one cause). #77608 (task inherits an unusable
binding from the creating session — SSH workspace there, frozen Space here; same class).
#76968 (scheduled-tasks MCP not exposed to some sessions — relevant because it limits where a
user can recreate a task from).

• Secondary doc bug: the help article "Schedule recurring tasks in Claude Cowork" still lists a

"Description of the task" field in the create modal. The current create form has none.

• Available on request: account/org/space/project UUIDs, the routine trigger id, the creating

session id, full scheduled-tasks.json before and after, and both log files.