hort down

Tear a sandbox down.

hort down [OPTIONS] <NAME>

Arguments:
  <NAME>  The sandbox to tear down

Options:
  -f, --force  Skip the confirmations for open sessions and unreturned work
  -h, --help   Print help

Examples

hort down fix-login      # asks first if sessions are open, or if a clone holds work you never sent out
hort down fix-login -f   # no questions

What it does

Always in this order, because deleting a directory that a running process still has mounted corrupts I/O:

1. Stops the notification watcher and the host-side network helpers (pasta, the egress proxy, database forwarders).
2. Removes the container, which ends every session and the anchor and releases the worktree mount.
3. In a git project, removes the worktree directory, including uncommitted changes, and its registration in your repository. In clone mode that directory is the sandbox's clone, so every commit made inside it that was not pushed or fetched out goes with it, which is why down asks first (see Unreturned work). That step also deletes the sandbox's pinned ref refs/hort/<name>/base from your repository; the pins of your other clone-mode sandboxes are left alone.
4. Removes hort's record of the sandbox.

It keeps the branch and its commits (deleting it from down is planned), your repository, and the project's dependency caches. In a project without git it never touches your folder: only the container and the record go.

down prints nothing when it succeeds.

Naming the sandbox is taken as your decision: down does not check for uncommitted work. Commit first. It asks two questions, and only two: about open sessions, and about commits that exist only inside a clone.

Open sessions

If processes are running in the sandbox besides its anchor (someone, or some agent, is inside), down asks on a terminal:

tear down sandbox 'fix-login' with open sessions? [y/N]

Only y or yes proceeds; anything else, including Enter, leaves the sandbox alone and exits 0. -f skips the question. Without a terminal and without -f, down refuses instead of guessing:

refusing to down without confirmation: stdin is not a TTY (pass --force to proceed)

Unreturned work

In clone mode the sandbox's /workdir is a repository of its own, so a commit made inside it lives nowhere else until it is pushed or fetched out. Before removing such a sandbox, down compares the clone's tip against your repository and asks on a terminal when your repository does not have it:

sandbox 'fix-login' holds commits the project repository does not have; tear it down anyway? [y/N]

Both reads happen on the host and neither needs the box running. Answering anything but y or yes leaves the sandbox alone and exits 0; -f skips the question; without a terminal and without -f, down refuses with the same message as above. If hort cannot read the clone at all, it asks anyway, because the alternative is deleting commits it could not see.

Worktree-mode sandboxes are never asked about: their commits go straight into your repository, so tearing the box down does not touch them.

Sandboxes in other states

• orphaned: there is nothing running to stop; down removes the worktree and the record.
• inconsistent (worktree deleted on the host): down stops the container and clears the stale worktree registration and the record.
• lost-record: hort has no record, but the container is running. down stops the helpers and the container and stops there, because the worktree's path was in the missing record. See Troubleshooting for what may be left on disk.

Messages

In clone mode, down also deletes that sandbox's pinned ref refs/hort/<name>/base from your repository, so the commit it was holding for the clone becomes collectable by git gc again. Pins belonging to your other clone-mode sandboxes are untouched: each one keeps your repository's gc off the objects that clone is still borrowing.