Cancel Clone

Stop a clone the caller started, by the id its stream announced.

Cancelling used to be nothing more than the client hanging up: closing the response tore down the exec stream, which killed the child, which let the cleanup run. That holds on a direct connection and is how desktop still works. It does not hold in a hosted deployment -- the load balancer in front of the API keeps draining the response after the client aborts, so no disconnect is ever delivered, the handler runs on, and none of the cleanup that hangs off that teardown happens. Drilled on dev 2026-09-02: an aborted clone was still writing its pack file minutes later, and the workspace was left holding a .git that refused the next clone.

So the client says so. Killing the child is all this route does: the stream then ends on its own with a signal exit, and the terminal-result path in :func:_relay reports the failure and sweeps the root -- still gated on git's own start line, so the invariant that only a clone's own files are ever deleted is unchanged.

Answering 404 for an unknown id is deliberate: a command that already finished and a box that never had it both mean nothing is running.