Permanently erase a file's contents

tovio obliterate <hash> --confirm "obliterate <hash>" --reason "leaked credential"

Permanently erases an object's payload, leaving a signed tombstone in its place.

This is not undoable

Everything else in TOVIO reverses with tovio undo. This does not. The confirmation string must be typed exactly — it is obliterate followed by the same object hash you passed as the argument — because it is the last check between you and permanent loss.

A bare --yes is not accepted. It is recognised only so it can be rejected with a clear message rather than looking like an unknown flag, and it exits with a usage error.

Say why

--reason is recorded verbatim in both the signed tombstone and the audit entry. It is technically optional — omit it and a generic placeholder is recorded — but an obliteration whose reason reads "explicit operator-requested obliteration" is a hole in your own record six months later. Always pass one.

If you want that enforced rather than advised, put obliterate in the justification policy: tovio policy audit --require-for obliterate --minimum-length 40. The reason then has to arrive as --justification as well, and the command is refused before anything is erased.

Only a human, and only the owner

Obliteration requires the repository owner's identity. Agents cannot do it, delegated clone identities cannot do it, and a keyless repository cannot do it — there is deliberately no token or agent authorization path at all. It is absent from the agent and MCP surfaces for the same reason: irreversible destruction stays a human action.

If the object is policy-encrypted, you also need a key that can actually unwrap it. Being able to see that an object exists has never been the same as being allowed to destroy it.

When it is the right tool

• A credential committed in the clear and pushed.
• Personal data that must be erased under a legal obligation.
• Content that must not exist, where removing the reference is not enough.

What it leaves

A signed tombstone, bound into history so it stays reachable after its target disappears. History stays coherent: a read of the erased address returns a typed "this was obliterated" result, never a 404 and never corruption. Garbage collection never removes a tombstone. The erasure itself is recorded in the audit chain and the op-log. It is not a way to quietly rewrite the past.

Packs are immutable, so the store is unpacked to loose objects before the payload can be physically removed. On a large repository this takes a while and is not a failure.

Rotate anyway

If a credential was pushed, assume it is compromised. Obliterating the object does not un-copy it from anyone who synced. Rotate the credential first, then obliterate.