claude-code - 💡(How to fix) Fix [FEATURE] Cowork: allow configuring the storage location for scheduled tasks (currently hardcoded to ~/Documents/Claude/Scheduled/) [6 comments, 3 participants]

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 (#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 (#43197) and "outside home directory" mount failure (#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 (#34604 for default workspace folder, #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 #54744, #34667, and #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.