[FEATURE] Cowork: allow configuring the storage location for scheduled tasks (currently hardcoded to ~/Documents/Claude/Scheduled/)

[aleozlx]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Cowork stores scheduled task definitions at the hardcoded path ~/Documents/Claude/Scheduled/<task-name>/. There is no setting in the app to change this location.

The hardcoded path under a TCC-gated, user-redirectable folder causes a class of bugs that can't be cleanly fixed at the symptom layer:

• macOS Documents folder TCC denial → cryptic VirtioFS mount error on every session init ([BUG] Cowork: Session init fails to mount scheduled task config folder outside project mount after macOS Desktop upgrade #54744). The TCC prompt at first launch can be dismissed without context, and the resulting failure gives no actionable signal that Documents access is missing.
• Corporate / managed Macs where Documents is subject to MDM policies, DLP scanning, or principle-of-least-privilege restrictions on app access — frequent small-file writes from scheduled tasks conflict with these.
• Windows Documents redirection to D:\ or other non-system drives → cross-drive hard-link failure ([BUG] Claude CoWork does not support Windows 11 setups w/two hard drives and Documents on the D:\ drive. #43197) and "outside home directory" mount failure ([BUG] Cowork Scheduled Task — SKILL.md Not Accessible From Session VM (Windows, Non-Standard Documents Path) #34667).
• User preference — users who keep ~/Documents clean and put app-managed data elsewhere have no way to redirect Cowork.
  Two adjacent feature requests exist ([FEATURE] Cowork: Allow setting a default workspace folder for all sessions #34604 for default workspace folder, [FEATURE] Add a persistent default output folder setting for Cowork sessions #47179 for default output folder) but neither covers the scheduled-task storage root specifically.

Proposed Solution

Add a configurable storage location for scheduled tasks, with a sensible new default:

1. Change the default to an app-managed, non-TCC-gated location. ~/Library/Application Support/Claude/Scheduled/ on macOS and %APPDATA%\Claude\Scheduled on Windows are the conventional locations for app-managed user data. This single change would eliminate [BUG] Cowork: Session init fails to mount scheduled task config folder outside project mount after macOS Desktop upgrade #54744, [BUG] Cowork Scheduled Task — SKILL.md Not Accessible From Session VM (Windows, Non-Standard Documents Path) #34667, and [BUG] Claude CoWork does not support Windows 11 setups w/two hard drives and Documents on the D:\ drive. #43197 without requiring any user-facing configuration.
2. Expose a preference in Settings → Cowork → "Scheduled tasks location" for users who want a custom path.
3. Support a config-file field for power users and managed deployments:

   { "cowork": { "scheduledTasksRoot": "~/cowork-data/Scheduled" } }

For users who already have tasks at ~/Documents/Claude/Scheduled/, a one-time migration on update — or a symlink from the new location to the old — would preserve backward compatibility.

Alternative Solutions

No response

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Scenario: a user on a corporate-managed Mac installs Claude Desktop. The macOS TCC prompt for Documents folder access appears during onboarding without explaining that Cowork's scheduled tasks specifically depend on it. The user dismisses or denies the prompt.

1. User opens Cowork and creates a scheduled task ("daily morning briefing")

2. Task creation succeeds; the UI shows the task as configured normally

3. User attempts to run the task or starts any new Cowork session

4. Session fails immediately with RPC error: failed to mount ... operation not permitted

5. User has no in-app indication that the failure is due to a missing TCC grant on ~/Documents/

6. User files a bug report or gives up on Cowork
   With the proposed fix (default storage moved to ~/Library/Application Support/Claude/Scheduled/):

7. User opens Cowork and creates a scheduled task

8. Task is stored in app-managed location, no TCC dependency

9. Task runs successfully regardless of Documents folder permission state

Additional Context

Filed alongside #54744 (the bug this would structurally prevent). Cross-platform — applies to macOS and Windows.

The same architectural choice — app state under ~/Library/Application Support/ on macOS and %APPDATA% on Windows — is already used by Claude Desktop for vm_bundles/, MCP server configs, and other internal state. Scheduled tasks are the outlier in living under a user-visible, TCC-gated location.

If user-visible access to scheduled-task definitions is a deliberate design choice (e.g., so users can edit SKILL.md files directly in Finder), a symlink from ~/Documents/Claude/Scheduled/ → ~/Library/Application Support/Claude/Scheduled/ would maintain that affordance while moving the canonical storage out of the TCC-gated path.

[github-actions]

Found 3 possible duplicate issues:

1. [Feature Request] Add configurable storage path for scheduled-tasks SKILL.md files #52430
2. [BUG] Cowork: Session init fails to mount scheduled task config folder outside project mount after macOS Desktop upgrade #54744
3. [FEATURE] Configurable path for all Claude files that are written in my home dir #31284

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This is path-assumption rigidity at the scheduled-task boundary.

If Cowork hardcodes scheduled task storage to ~/Documents/Claude/Scheduled/, then the feature is binding operational state to one host-path assumption that may not fit users' actual filesystem, privacy settings, sync strategy, or managed environment constraints.

Why it matters:

• scheduled tasks are long-lived operational state, so storage location is not a trivial preference
• hardcoded paths break more often on managed machines, nonstandard home layouts, externalized docs folders, and privacy-restricted desktops
• once the path is fixed in product logic, users cannot adapt the feature to the environment they actually run

I would want clarity on:

1. whether the current path is assumed by UI only, runtime only, or multiple layers that would need coordinated override support
2. whether the product needs just a configurable root path or a more general storage provider abstraction
3. whether path validation / permissions checks could be surfaced proactively so users know when the configured location is invalid before task failures occur

Operational features need environment-flexible storage semantics. If scheduled tasks depend on one hardcoded folder, the system is forcing a host assumption into a place where reliability depends on configurability.

[aleozlx]

whether the current path is assumed by UI only, runtime only, or multiple layers that would need coordinated override support

it's opaque therefore unclear. (i didn't check source code etc)

[aleozlx]

whether the product needs just a configurable root path or a more general storage provider abstraction

in my mind / use case. it's just a path

[aleozlx]

whether path validation / permissions checks could be surfaced proactively so users know when the configured location is invalid before task failures occur

yes, more understandable / precise errors would be very helpful

[aleozlx]

why not dup

#52430. different platform

#54744 different problem statement, not the same ask. i filed this one myself separately

#31284 different subject, not the same folder in question

[lejacobroy]

This hardcoded path is preventing our team from using Claude Cowork Sheduled Tasks.
Minimaly, a root path entry in claude_desktop_settings.json would be added to configure the Sheduled Tasks parent folder.
From my quick look at the source code, the path is hardcoded at a lower level, not UI.

[lejacobroy]

Proposal: configurable Cowork workspace paths (consolidates #57177, #54859, #54138, #52496)

Root cause (shared across all four issues)

Claude Desktop / Cowork resolves three storage roots from a single hardcoded base, ~/Documents/Claude/:

• ~/Documents/Claude/ — Cowork workspace base
• ~/Documents/Claude/Artifacts/ — Live Artifacts mount source
• ~/Documents/Claude/Scheduled/ — scheduled task definitions

There is no user-facing setting and no claude_desktop_config.json field to override any of these. The result is a class of failures on otherwise-supported setups: macOS TCC denial on ~/Documents, OneDrive-synced Documents on macOS/Windows, Windows Documents redirected to D:\, MDM-restricted corporate Macs, and user folders kept outside ~/Documents by preference.

Proposed fix

1. New default location (no config required)

Move the canonical storage out of the TCC-gated, user-redirectable Documents folder:

• macOS: ~/Library/Application Support/Claude/Cowork/
• Windows: %APPDATA%\Claude\Cowork\
• Linux: $XDG_DATA_HOME/Claude/Cowork/ (fallback ~/.local/share/Claude/Cowork/)

This is consistent with where Claude Desktop already stores vm_bundles/, MCP configs, and other app state. It eliminates the TCC, OneDrive, and cross-drive failure modes without any user configuration.

2. Single configurable base path in claude_desktop_config.json

{
  "cowork": {
    "workspaceRoot": "~/Documents/Systems/Claude",
    "artifactsRoot": "~/Documents/Systems/Claude/Artifacts",
    "scheduledTasksRoot": "~/Documents/Systems/Claude/Scheduled"
  }
}

Resolution rules:

• If cowork.workspaceRoot is set and the sub-roots are not, derive artifactsRoot and scheduledTasksRoot as <workspaceRoot>/Artifacts and <workspaceRoot>/Scheduled.
• Any sub-root explicitly set overrides the derived value.
• ~ and environment variables ($HOME, %USERPROFILE%, %APPDATA%) are expanded.
• Paths are validated at startup: must be writable, must not cross a virtiofs-incompatible mount (OneDrive/iCloud Drive cloud-only files, cross-drive on Windows). On failure, fall back to the default and surface a one-time notification.

3. Equivalent UI setting

Settings → Cowork → "Workspace location" with a folder picker, writing to the same config field. UI and config must be a single source of truth.

4. Per-session override (fixes #54138, #52496)

When the user selects a project folder via "Use an existing folder", Artifacts and any per-session storage MUST mount relative to that folder (e.g. <sessionFolder>/.claude-artifacts/), not the global artifactsRoot. The global root is only used for sessions without a selected folder.

5. Migration

On first launch after the change:

• If ~/Documents/Claude/ exists and the new default location does not, move contents and leave a symlink at the old path for backward compatibility.
• If the user has set cowork.workspaceRoot, migrate to that location instead.
• Existing scheduled-tasks.json entries with absolute filePath values are rewritten to point at the new location.

Why one PR instead of four fixes

The four issues are symptoms of one architectural choice (hardcoded base under a TCC/cloud-sync-prone folder with no override). Fixing each surface independently leaves the other three reachable through different code paths. A single resolution layer that reads claude_desktop_config.json, falls back to the platform-appropriate app-data location, and honours per-session folder selection closes all four.

Acceptance criteria

• Default install on macOS with Documents access denied → Cowork, Scheduled tasks, and Artifacts all work.
• Windows with Documents redirected to D:\ → same.
• macOS or Windows with OneDrive-synced Documents → same.
• User sets cowork.workspaceRoot to an arbitrary path → all three storage areas land under it.
• User opens a session with "Use an existing folder" → Artifacts mount inside the selected folder, not the global root.
• Existing users with content at ~/Documents/Claude/ see no data loss after upgrade.

[lejacobroy]

This is fixed in the latest version, thank you!