[FEATURE] Cowork: Auto-mount user project folders in scheduled task sandboxes

Preflight Checklist

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

Problem Statement

Cowork scheduled tasks run in isolated sandboxes where user-selected project folders are not mounted. Folders connected via the Cowork UI are only available in interactive sessions — when a scheduled task fires, they do not exist in the sandbox.

This means tasks cannot access:

• Shared scripts and utilities (e.g., a Python API helper used across multiple jobs)
• Credentials stored in .env files
• Knowledge base documents (PDFs, reference files, playbooks)
• SKILL.md instruction files the task is designed to read

The only workaround is to embed all of this content directly in the task prompt, which is unsustainable.

Proposed Solution

Allow users to designate folders as "always mount" for scheduled tasks — either globally per project or per individual task — using the same VirtioFS/Plan9 mount infrastructure already used in interactive sessions.

Configuration could live in the task editor UI as a simple folder picker with a label like "Folders available during scheduled runs." When a scheduled task fires, those folders are pre-mounted before execution begins, exactly as they are when the user is present.

Secondary improvement: surface a clear, actionable error at task-definition time if the task prompt references a path from a folder that isn't configured to mount.

Alternative Solutions

If always-on mounting is too complex, a lighter-weight fallback would be:

1. Snapshot-and-inject: At the moment the user saves a scheduled task, snapshot the contents of specified folders and embed them as read-only virtual files in the task runtime. Stale if files change, but eliminates the "nothing is accessible" problem.
2. Explicit file references in task settings: Let users specify individual files (not whole folders) to be made available. Lower complexity than full folder mounting; addresses the most common use cases (one .env, one helper script, one knowledge base file).

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

I'm running a production customer support automation system (Charlie's Custom Clones, Reamaze inbox) with three scheduled jobs:

• Job A (every 15 min): Regex-based order number tagger. Reads SKILL.md and a shared Python script (helper.py) that wraps the Reamaze HTTP API.
• Job B (every 2h weekdays): AI-driven conversation summarizer. Reads SKILL.md, helper.py, a .env credentials file, and a 10-document knowledge base (customer service PDFs).
• Job C (every 20 min): Prospect emailer. Same pattern.

Because none of these folders mount in scheduled tasks, the current workarounds are:

1. Inline scripts: helper.py (~300 lines) is copy-pasted into every task prompt. A single bug fix now requires manually updating 3 separate prompts.
2. Inline credentials: The Reamaze API token is hardcoded in prompt text instead of read from .env.
3. Inline knowledge base: 10 PDFs were condensed to a plain-text summary embedded in the prompt — losing nuance, and requiring every task prompt to be edited whenever policy changes.
4. Silent failures: When a file isn't found, tasks fail without clear indication of why, making debugging difficult.

Additional Context

Several related issues point to the same root cause:

• #34667 — SKILL.md inaccessible from scheduled task VM (Windows)
• #37713 — Dispatch sessions fully isolated from Projects (no shared context or working directory)
• #47180 — "Always allow" folder/tool permissions don't persist across scheduled runs
• #47179 — Feature: persistent default output folder for Cowork sessions
• #34604 — Feature: default workspace folder for all sessions

A detailed writeup with technical context, current workaround costs, and a proposed implementation approach is attached.

Cowork Scheduled Tasks.docx