[BUG] Cowork regression: existing Scheduled Tasks + Live Artifacts broke after Aug 29 migration (macOS)

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?

What broke?

A late-August Claude Desktop / Cowork update appears to have broken two parts of my existing local Cowork setup at the same time:

1. Existing Scheduled Tasks lost their local workspace
2. Existing Live Artifacts became effectively read-only

Both failures have the same shape: the persistent object survived the migration, but the binding/tooling Cowork previously used to operate on it did not.

Both systems were working before the update.

Both still exist after the update.

The problem is that the connections Cowork used to actually operate on them seem to be gone.

I'm on macOS / Apple Silicon, Claude Desktop 1.40609.1, Pro.

---

1. Scheduled Tasks now run in Scratchpad instead of their original workspace

I had three scheduled Cowork jobs running against a local ~/Cowork workspace:

• Daily system maintenance
• Weekly system optimization
• Monthly system integration

These are not reminder tasks. They maintain persistent local state: liveness/state checks, captured-context promotion, write verification, hot-cache rendering, task/memory verification, system-health checks, weekly optimization, and monthly integration.

After the update, the tasks survived and still fire, but my Daily system maintenance job now fails with:

The Cowork vault directory doesn't exist at ~/Cowork.

Except ~/Cowork absolutely does exist and still works normally in regular Cowork sessions.

The key clue is visible directly in the run UI:

Working folder: Scratchpad

There is no option on the existing task to change that back to ~/Cowork.

So from what I can tell, the migration preserved the task definition and schedule but dropped the local working-folder binding.

Repro / observed behavior

1. Open an existing pre-migration scheduled task that depends on a local workspace.
2. Run it or inspect a scheduled run.
3. It reports that ~/Cowork doesn't exist.
4. Open the Context panel.
5. Working folder = Scratchpad
6. Open a normal Cowork session.
7. The exact same ~/Cowork workspace works normally.
8. There is no option on the existing scheduled task to restore/change its working folder.

---

2. Existing Live Artifacts also became effectively read-only

The same update window also broke editing of existing Cowork Live Artifacts.

The artifacts are still present and render normally.

Cowork can still read/stage the existing artifact by artifact ID.

But fresh Cowork sessions no longer have the artifact-management tools that previously handled updates:

mcp__remote-devices__list_artifacts

mcp__remote-devices__update_artifact

mcp__remote-devices__create_artifact

In a completely fresh local Cowork session, Claude reported:

There is no remote-devices MCP server registered in this session at all.

I also tested:

• switching Settings → Cowork → Only on this computer ON
• fully quitting Claude
• reopening it
• creating a brand-new local Cowork task

The artifact tools were still absent.

At the same time, ~/Claude/Artifacts is explicitly treated as a protected location, so it cannot simply be mounted as a normal Cowork folder.

That leaves a strange dead end:

• existing artifact still opens
• artifact-specific read path still works
• normal Cowork writes to the artifact store are blocked
• artifact-specific update tools are missing

The artifact UI itself only gives me Unpin / Download as PDF / Delete. There is no edit/migrate/reconnect option.

---

Migration timing

At approximately 01:38 on Aug 29, Claude Desktop created the new:

~/Claude/Artifacts/

~/Claude/Scheduled/

structure.

The parent directories have the Aug 29 timestamp, while the existing artifacts and scheduled-task directories inside them retain their older timestamps.

My scheduled tasks date back to June. My artifacts predate the migration as well.

That looks like existing persistent Cowork state was moved into a new storage structure rather than recreated.

This is also when these workflows stopped behaving normally.

I can't prove that the filesystem migration itself caused both failures, but the timing and the affected subsystems seem too closely aligned to ignore.

---

Expected

A Desktop/Cowork migration should preserve the relationships that make existing persistent workflows work.

For Scheduled Tasks:

task + schedule + working folder

For Live Artifacts:

artifact + supported read/write/update path

If something needs to be reauthorized or migrated, Claude should tell the user and provide a way to do it.

---

Actual

The persistent objects survived, but critical parts of their execution plumbing didn't.

Scheduled Tasks:

• task survives
• schedule survives
• task still fires
• original workspace is gone from the execution context
• task now runs in Scratchpad

Live Artifacts:

• artifact survives
• artifact still renders
• artifact can still be read
• supported update tools are gone
• protected storage blocks the obvious fallback

So both systems still look intact in the UI while the workflows underneath them are broken.

That's a pretty nasty failure mode for persistent automation.

---

Related

The Scheduled Task behavior looks related to #86274 and #91095.

I'm filing the Live Artifact behavior here as part of the same migration regression because it broke across the same transition, but I'm happy to split that into a separate issue if the Cowork team would rather track the two surfaces independently.

---

Impact

This update broke the daily/weekly/monthly maintenance system and Live Artifact dashboards I had already built around Cowork.

I've been using Cowork as an actual persistent local agent environment, not just a chat window with reminders attached. That's one of the main reasons I moved so much of my workflow into Claude in the first place.

I've already been frustrated by some of the recent model/product changes, but I was willing to live with that because Cowork's local persistent workflow was genuinely different and useful.

This is the first update that has made me seriously question whether I can keep building important systems around Claude if an app migration can silently disconnect workflows that were already working.

I don't want to rebuild all of this somewhere else. I'd much rather Anthropic fix the regression.

Happy to test a fix or provide more sanitized diagnostics if someone from the Cowork team wants to dig into it.

What Should Happen?

Existing persistent Cowork workflows should survive a Desktop migration with their operational bindings intact.

Scheduled Tasks should retain the local workspace they were created against, and existing Live Artifacts should remain editable through the supported artifact tools.

If either needs to be reauthorized or migrated, Claude should surface that explicitly and provide a way to reconnect it rather than leaving the object visible but non-functional.

Error Messages/Logs

The Cowork vault directory doesn't exist at ~/Cowork.

Context → Working folder: Scratchpad

Fresh Cowork session:
mcp__remote-devices__list_artifacts — not available
mcp__remote-devices__update_artifact — not available
mcp__remote-devices__create_artifact — not available

Claude reports no remote-devices MCP server registered in the session.

Steps to Reproduce

Scheduled Tasks:

1. Open an existing pre-migration scheduled task tied to a local workspace.
2. Inspect or run it.
3. It reports that ~/Cowork doesn't exist.
4. Context shows Working folder = Scratchpad.
5. The same ~/Cowork workspace works normally in a regular Cowork session.
6. There is no option to restore the task's working folder.

Live Artifacts:

1. Open an existing pre-migration Live Artifact. It still renders normally.
2. Start a fresh Cowork session and inspect available artifact tools.
3. list_artifacts, update_artifact, and create_artifact are absent.
4. Switching Cowork to "Only on this computer", fully restarting Claude, and starting a fresh task does not restore them.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Was working before Aug 29, 2026; regression noticed immediately after the late-August Desktop/Cowork migration.

Claude Code Version

N/A — Claude Desktop / Cowork, not Claude Code CLI. Claude Desktop 1.40609.1.

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

This is a Claude Desktop / Cowork regression, not a Claude Code CLI issue.

The key pattern is that both affected persistent objects survived the Aug 29 transition, while the mechanisms Cowork used to operate on them did not:

Scheduled Task survives → workspace binding becomes Scratchpad
Live Artifact survives → still renders/reads, but artifact update tooling disappears

Both began failing across the same migration window when the new ~/Claude/Scheduled and ~/Claude/Artifacts structure appeared.

Related scheduled-task reports: #86274, #91095.

I have also opened a private Anthropic Product Support case with a more detailed diagnostic brief and can provide sanitized logs/timestamps if useful.

<img width="729" height="341" alt="Image" src="https://github.com/user-attachments/assets/c8dc28b7-02c2-4edb-9c3d-fa2876f45bb1" />