{"version":"2.1.260","anchor":"job-deletion-can-discard-confirmed-unpushed-worktree-commits","canonical_anchor":"job-deletion-can-discard-confirmed-unpushed-worktree-commits","heading":"Deleting a job\/session can now discard confirmed unpushed worktree commits","tier":"use","area":"Sessions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.260\/e\/job-deletion-can-discard-confirmed-unpushed-worktree-commits","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.260","markdown":"### Deleting a job\/session can now discard confirmed unpushed worktree commits\n\nBackground job worktree deletion can now discard confirmed unpushed commits with a re-confirm step.\n\nDeleting a background job's worktree previously refused outright when it held commits not pushed to any remote. Now a caller can pass a `discardUnpushed` pin (`headSha` plus `worktreeDigest`), and if the worktree's HEAD still matches that pin the removal proceeds despite the unpushed commits. If the pin no longer matches, or the unpushed commits are also referenced by another job's state, the kept-worktree reasons `unpushed` or the new `unpushed_shared` are returned instead, along with `keptUnpushed`\/`discardUnpushed` info so the caller can re-confirm; `unpushed_shared` specifically refuses to offer a discard when another finished job's `state.json` also references the same worktree, to avoid destroying another session's output.\n\nIn the Fleet UI, deleting a session whose worktree has unpushed commits no longer fails silently: it reports the unpushed count and prompts to delete again to discard, tracking a `discardOffer` so a second delete forces `discardUnpushed`.\n\n- Area: Sessions\n- Names: `discardUnpushed`\n- Tier: Use it now\n- Useful: 2\/5\n- Signal: 1\/5"}