Clearing a workspace that sits outside every folder (the one removal Omniscio will not do by itself)
How a workspace (git worktree) that sits outside every folder Omniscio manages gets cleared, now that nothing else can touch it: the inbox card that reports it carries a button, clicking the button raises one approval per workspace, and approving an approval removes it — folder gone, branch kept. Covers what the app refuses to remove even then, what the removal still checks, and how an agent reaches the same outcome from the CLI.
What it is
Every agent workspace (git worktree) Omniscio creates lives inside a folder it is configured to use, and it reaps them from there. A workspace that ends up anywhere else — one an agent made by hand at a typed-in path, say — is a different thing: nothing proves Omniscio created it, so nothing in Omniscio deletes it. That refusal is deliberate and stays.
What was missing was the other half. The health check ("Agent workspaces have nowhere safe to go") reports those workspaces to you, but no road could remove one — so the card could never clear, and there was no control to act on. This is that control: the card now carries Clear unreachable workspaces, which asks for the reported workspaces to be cleared.
Where to find it
- The inbox. The card titled Agent workspaces have nowhere safe to go carries the button.
- From a terminal or an agent, the same outcome is reached through the ordinary removal call,
POST /worktrees/<id>/remove— see For agents below.
How it behaves
- Clicking the button deletes nothing. Omniscio re-derives the stranded list from git at that moment (the count on the card is a fact about when it was raised) and raises one approval card per workspace, each naming the full folder path.
- Approving a card is what removes the workspace. A card you reject is a final answer: no setting and no later call overturns it, and no replacement is raised for the same workspace.
- The folder goes; the branch stays. Every commit remains on a durable ref inside the repository, so freeing space never destroys work.
- Unsaved or ignored work still holds it. Those protections are unchanged. When one refuses, nothing is deleted: you are told which protection held, and a fresh approval is raised straight away. The card you clicked is spent — one card covers one attempt — so clearing the obstruction and approving the new card is the way through. You are never left holding an approval that can no longer do anything, and the workspace never becomes unanswerable.
- The app's own checkouts are never removable this way. The cloud build checkout, an
_ops-*baseline pin, the auto-lander's recovery tree and the boot-probe tree refuse every road, including this one. - Nothing is removed from a request. The waiver is a stored, approved card bound to that exact workspace — a caller cannot ask for it.
For agents
An agent gets the same outcome through the removal call it already makes:
POST /worktrees/<id>/remove
For a workspace outside every folder, the refusal now names the approval card and states that approving it removes the workspace — so an agent is never left at a dead end. It is not told to re-run: that card's approval performs the removal itself, unlike the deliberate-retire card for a branch whose work cannot be found, which is acknowledge-only because the caller re-runs.
Related
- Orphaned Workspace Archive — the ordinary reclaim path for workspaces inside the managed folders, which frees the disk and keeps the work.
- Dev Pipeline panel — the Worktrees view that lists what a repo holds.
Last verified 2026-09-30