Verified 2026-08-05 What was checked, and when — not a guarantee it is still true.
Every Cowork-mounted directory denies exactly two operations by default: removing a file and removing a directory. Both fail with a permission error. Truncating a file, renaming within the mount, and renaming onto an existing file all succeed — so a file disappearing from its old path is not evidence that anything was deleted. Deletion can be enabled, but only per-mount, only by asking the user, and only for the rest of that session.
Enabling deletion requires a prompt the user must accept, and it is presented as irreversible for the remainder of the session. It also fires regardless of how permissive the session's permission mode is. A skill that routinely needs deletions will routinely interrupt its user, so prefer writing new files over rewriting in place.
Approval is granted per mount. Enabling deletion for the outputs location leaves a connected folder still denied, in the same shell and in later ones. A skill that gets one approval and then assumes free rein across the workspace will fail on the second mount it touches.
Caveat: Established with a control: an unapproved connected folder stayed denied while the approved location succeeded.
The outputs location is a genuinely separate device from the rest of the session filesystem, so renaming across that boundary fails with a cross-device error rather than falling back to a copy. Shell tools usually degrade to copy-then-delete on their own — and the delete half will then hit the permission denial.
The denied set is exactly those two operations. This is not specific to the outputs location — a freshly connected folder behaves identically. The failure is a permission error, not a missing-file error, and it happens even though the same directory is writable.
Caveat: Measured in the default configuration; see this page's open question about fully sandboxed organisations.
The permission tool's own description instructs the agent to request approval whenever a removal fails, rather than reporting it as impossible. So a skill that merely attempts a delete may cause a prompt it never asked for. If you do not want that, do not attempt removals.
Truncating a file to zero length, renaming it within the mount, and renaming it onto an existing file all succeed. The last of those destroys whatever was at the destination. So content can be emptied and paths can be reused without any delete having occurred, and a check based on 'the old path is gone' will report deletions that did not happen.