[Feature] Session manifest + smart cleanup: persist session DNA to user folder, delete rebuildable VM state on exit #39540

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's VM accumulates working state across sessions with no mechanism to release it other than a binary "clean up" dialog that deletes everything. Two compounding problems result: (1) the VM disk fills up with rebuildable intermediate state — installed packages, temp scripts, execution logs, sub-agent scratch files — that has no path to the user's folder; (2) genuinely valuable working files are silently lost when the VM recycles on context overflow (see #30364). The system holds onto too much and loses things it shouldn't, simultaneously.

Proposed Solution

At session start, Cowork writes a lightweight manifest file to the user's mounted folder. The manifest records: task name and timestamp, input files referenced, packages installed and versions, intermediate files generated, and final outputs flushed. On session exit (or before VM recycle), Cowork evaluates each item: if it can be recreated from the manifest + user folder, delete it from the VM; if not, flush it to the user folder first. On session recall, Cowork reads the manifest and reconstructs the environment from scratch. This is the standard pattern in reproducible build systems (Nix, Docker layer caching). A simple JSONL or TOML file per session, written incrementally so it survives mid-session crashes, would suffice.

Alternative Solutions

The only current workaround is the binary "clean up" dialog, which deletes all session state with no granularity. Users who want to preserve anything must manually copy files out of Cowork before cleaning. There is no way to selectively persist rebuildable vs. non-rebuildable content, and no way to resume a session without carrying forward the full VM state.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

A user runs three Cowork sessions over two weeks: transcribing notes, drafting a report, and analysing a spreadsheet. Each session installs pip packages and generates intermediate files inside the VM. After two weeks the VM disk is nearly full (8 MB free of 9.7 GB). The only option is a full clean that may discard unsynced outputs. With a session manifest, each session would have flushed its outputs to the user folder on exit and cleared its rebuildable state, keeping VM usage roughly constant regardless of how many sessions accumulate.

Additional Context

Related bugs: #30364 (silent file loss on VM recycle) and the "workspace disk full" warning that currently offers only a binary clean/keep choice. The manifest pattern has direct precedent in Nix, Docker layer caching, and Make — the core insight being that a reproducible description of an environment is always cheaper to store than the environment itself.