---
title: "Cancel Clone"
method: POST
path: "/api/workspace/git/clone/cancel"
tags: ["runtime_mutations", "git"]
---

# Cancel Clone

`POST /api/workspace/git/clone/cancel`

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.

## Response `200`

Successful Response

- unknown

## Changes

- **2026-09-03** `f0da1998fe85` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/quadrillion/apis/quadrillion-cloud-api/changes/api/workspace/git/clone/cancel/post.md)

---

[API](https://skmtc.dev/quadrillion/apis/quadrillion-cloud-api.md) · [All operations](https://skmtc.dev/quadrillion/apis/quadrillion-cloud-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/quadrillion/quadrillion-cloud-api/revisions/f0da1998fe85/schema)