Why does deleting a file fail, and what should my skill do?
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.
Treat needing a delete as a design smell, because getting one interrupts the user.
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.
As of the 2026-08-05 capture · Desktop 1.25927.0 · not individually re-checked since this rule last changed
Do not assume that approval to delete in one location applies anywhere else.
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.
As of the 2026-08-05 capture · Desktop 1.25927.0 · not individually re-checked since this rule last changed
Do not move files between mounts with a rename. Copy, then verify.
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.
As of the 2026-08-05 capture · Desktop 1.25927.0 · not individually re-checked since this rule last changed
Expect removing a file or a directory to fail with a permission error on every Cowork mount.
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.
As of the 2026-08-05 capture · Desktop 1.25927.0 · not individually re-checked since this rule last changed
Expect the agent to ask for delete permission on its own the first time a removal fails.
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.
As of the 2026-08-05 capture · Desktop 1.25927.0 · not individually re-checked since this rule last changed
Do not treat a file vanishing from its old path as evidence that it was deleted.
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.
As of the 2026-08-05 capture · Desktop 1.25927.0 · not individually re-checked since this rule last changed
What is not established
- This was measured in the default configuration. Organisations that require a fully sandboxed VM take a different internal code path for enabling deletion, and nobody has measured whether it behaves the same way. Treat the approval mechanics, but not the deny-set, as unverified there.