claude-code - 💡(How to fix) Fix [FEATURE] Cowork: per-task-title retention policy for scheduled-task session residue

Problem

Scheduled tasks in Cowork each spawn a fresh session per run. The session is runtime residue — the task's actual outputs (files written, signals emitted, scripts run) persist on disk independently. The session record itself contributes nothing after the run completes.

For power users running multiple recurring tasks (e.g., daily Pulse brief + daily glossary sync + weekly Cast freshening), this accumulates ~14 sessions per week. With Cowork's 9.7 GB workspace disk cap, this fills the disk and forces periodic manual cleanup via the "Workspace nearly full" dialog.

Sub-problem: per-call approval on bulk archival

Compounding the disk-pressure issue: mcp__ccd_session_mgmt__archive_session is hardcoded to always prompt for per-call user approval ("requires user approval and is unavailable in unsupervised mode"). This means that even when a user has explicitly authorized a bulk-archive sweep, each session archive requires an individual click. In my last sweep, archiving 19 stale sessions required 19 separate approval clicks — and a Routine-based auto-sweep is structurally impossible because Routines run unsupervised. The user is left with either (a) clicking through N approvals in a supervised session whenever disk pressure recurs, or (b) accepting unbounded accumulation.

If the per-call approval is the intended security model, please add at minimum a "Approve all N archives in this batch" affordance in the dialog. The current UX makes manual catch-net workflows brittle at scale.

What I'd like

Primary ask — retention policy: in Cowork settings:

• Per-task-title allowlist — sessions matching a user-defined title pattern (exact match or glob) auto-archive after N days
• Default off — opt-in to preserve current behavior for users who treat sessions as work history
• Configurable threshold — N days defaults to e.g. 7, user-overridable

Secondary ask — batch-approve dialog: if the always-prompt model on archive_session is intentional security policy, surface a "Approve all N in this batch" button in the approval dialog when Claude is calling archive_session multiple times in a single turn. The current N-individual-clicks UX makes manual bulk-archive workflows painful enough that users avoid them, which compounds the disk-pressure problem the retention policy is meant to solve.

Why this is the right layer

User-space workarounds are possible (and I've built one — a weekly Routine that calls list_sessions + archive_session for matching titles). But they hit a wall: archive_session refuses to run in unsupervised (auto / bypass-permissions) mode, which Routines inherit. Even when the workaround works in a supervised session, every Cowork user with recurring tasks is reinventing the same retention loop.

CCD already knows which sessions belong to scheduled tasks (the session's origin is metadata Cowork holds). A first-class retention policy puts the lifecycle decision where the lifecycle is owned.

Alternatives considered

1. Routine with list_sessions + archive_session — works in supervised mode (with N clicks), structurally blocked in unsupervised. Fragile.
2. SessionEnd hook — archive_session blocks current-session self-archive, so the hook would have to dispatch a separate sweep agent anyway. Same architecture as Routine, more complexity, same unsupervised block.
3. Manual cleanup via "Workspace nearly full" dialog — current default. Reactive, not proactive.

Related

• #37581 — Cowork VM disk full
• #54859 (experimental) — Storage location configurability request

Why I'm filing this

I'm running 4 enabled scheduled tasks (Pulse daily brief, engagement glossary sync, Cast freshening weekly, weekly overwatch sweep). At ~10–14 cron sessions/week, the in-app "Clean up" dialog is necessary every 1-2 months. A retention policy would eliminate the periodic interruption, and a batch-approve dialog would make the manual sweep workflow tolerable in the meantime. Together they'd free Cowork users from rebuilding this workaround.