Archive, restore and delete

Tasks and projects can be changed, put away and removed from the web app, the command line, the REST API and the MCP tools. They all follow the same rules, so what you do in one place is what the others show.

Archive first

Archiving hides a task or project from lists and from task selection. Nothing is lost: the history, the evidence and the audit trail stay on record. An archived item can be brought back for 30 days. After that a scheduled job removes it, and a read of its identifier answers 410 Gone so nobody mistakes it for a typo.

overlane task archive task-7
overlane task list --archived        # what can still be restored, with the days left
overlane task restore task-7

Archiving a project archives its open tasks with it, and restoring the project restores exactly those tasks. A task you archived on its own stays archived.

Lists hide archived items unless you ask for them: add archived=true to a list request, --archived to a list command, or pick Archived in the web app.

Delete is archive with an end date

Deleting archives the item first, so a delete is undone the same way as an archive, within the same 30 days.

overlane task delete task-7 --dry-run   # see what would happen
overlane task delete task-7 --force

A task that holds a lease, or that has recorded evidence, is never deleted. The answer is a 409 that names the two choices:

• Cancel the task. It stops, any lease on it ends, and it stays on record as cancelled.
• Archive it. It leaves the lists and its history is kept.

A project with such a task behaves the same way. The web app shows this choice in a dialog instead of an error, with the cancel and archive buttons side by side.

Change a task or a project

A task’s title and outcome can be edited while it is open. The acceptance criteria and the required checks do not change here, because they only get stricter, through a contract change. A project can be renamed, and its code settings changed, by a role that manages policy.

overlane task update task-7 --outcome "Add CSV and JSON export"
overlane project update --name my-app

Issues, labels, cycles, work projects, saved views and loops

The planning records of a project follow the same rules. Each one can be changed, archived, restored and, except for issues, deleted.

overlane issue archive iss_ab12cd34ef56gh78
overlane issue list --archived
overlane issue label update lbl_ab12cd34ef56gh78 --name defect
overlane issue cycle update cyc_ab12cd34ef56gh78 --ends 2026-10-25
overlane issue project archive wpr_ab12cd34ef56gh78
overlane view update viw_ab12cd34ef56gh78 --name "Most urgent"
overlane loop delete lop_ab12cd34ef56gh78 --force

• An issue is archived, not deleted. An archived issue leaves lists, views and loops, and can be opened by its identifier. An issue whose task holds a lease is being worked, so archiving it is refused with a 409 until the lease ends.
• A cycle, label or work project that issues still use cannot be archived or deleted. The 409 says how many issues use it; move them first.
• A saved view or a loop can be archived or deleted at any time. An archived loop never fires.
• Archived records keep their names, so a new label cannot take the name of an archived one until the archived one is restored or removed.
• After 30 days a scheduled job removes the record and its audit trail of field changes, and a read of its identifier answers 410 Gone.

GitHub

With sync set to write-back, archiving an issue that is linked to a GitHub issue closes that GitHub issue, and restoring it reopens it. With sync read-only or off, nothing is sent to GitHub. Overlane never deletes a GitHub issue, and a close that Overlane made itself does not change the archived issue when GitHub reports it back.

Agents

Agents change these records through the harness_work MCP tool. Issue titles and descriptions come back wrapped as untrusted data with a notice: text in an issue is never an instruction. When an issue becomes a task, its title is quoted in the task’s prompt in the same way.

Who can do what

Changing a task needs the write role. Archiving, restoring or deleting a project needs a role that manages policy. Changing, archiving, restoring or deleting an issue, label, cycle, work project or saved view needs the write role. Loops are scheduled work, so changing, archiving, restoring or deleting one needs a role that manages policy. Every change writes an audit event, so the audit log shows who archived, restored, deleted or purged what, and when.