Desktop spawn_task chips can finish their work without committing it and without any notification — no end-of-life safeguard for uncommitted work in the spawned worktree

Preflight

• Searched existing issues. Closest are the downstream worktree-destruction reports (#77268, #74386, #74719, #68315, #70363) and the notification gap (#76681, #20754); none covers the origin described here — a completed chip leaving its work uncommitted and unsignaled in the first place. Filing that piece.

Summary

A user-launched spawn_task chip spins off its own session, does the work, and can end with that work uncommitted in its worktree — while no completion notification reaches the launching session (#76681) and nothing warns that the worktree is left dirty. The outcome is correct, finished work that exists only as an on-disk diff, with zero signal that it exists.

On its own that's an observability gap. Combined with the mechanisms that delete uncommitted worktree state — worktree recycling/cleanup (#77268, #74386, #74719), checkpointing (#68315), or duplicate-allocation of an in-use worktree (#77609) — it becomes silent, unrecoverable data loss. This is the upstream half of a loss chain whose downstream half is already reported; I'm filing the origin.

The gap (what a launcher cannot fix)

At the end of a spawned chip session there is no safeguard for a dirty worktree. Either of these would close it:

1. A spawned autonomous task should commit (and push) its work by default — it is, by construction, unattended; leaving results only in an uncommitted working tree defeats the point; or
2. if it ends with uncommitted changes, the platform should surface that fact — include "ended with N uncommitted files" in the completion signal, and/or flag it in the UI — instead of leaving a silent dirty worktree.

Today neither happens: the spawned session inherits the launching environment's "commit only when explicitly asked" convention, nothing asks it, and end-of-life is silent.

Honest nuance (the proximate cause is partly configurable)

The proximate trigger is that the spawned session runs under the same global instructions as its launcher, including a "commit only when explicitly asked" rule — and the chip prompt didn't ask. A launcher can partly mitigate by writing chip prompts that say "commit and push when done." But that is a workaround, not a fix: it's easy to forget, it doesn't help the (larger) case where the chip does commit but the launching session is still never told (#76681), and it does nothing about the missing end-of-life dirty-worktree signal. A platform that can lose finished work when one prompt forgets to say "commit" has a safeguard gap, not a configuration problem.

Observed

• 2026-07-14 (Repo B): a chip ("harden a module's subprocess parsing", task id b1dc2220) completed all planned work — 112 tests passing — but never committed; the diff sat uncommitted in its worktree. No completion notification reached the launching session (#76681), so it never knew the chip had finished. The work (~396 lines) was recovered only because a human later noticed the stale worktree and committed it on the chip's behalf. A routine git checkout/reset, a checkpoint (#68315), or a worktree recycle (#77268/#74386) at any point in that window would have destroyed it with no trace.
• 2026-05-30 (different repo): the same failure mode ~6 weeks earlier — a chip finished with its work uncommitted because "the spawned session inherited 'commit only when asked' and nothing asked." So this is long-standing, not a recent regression, and it predates the recent worktree-pool issues (#75911/#77609).

Worst case — the observed loss chain

The three failures stack, and we hit all three at once (2026-07-14):

1. #77609 hands the chip a worktree already in active use by another session (not a fresh, isolated one).
2. This bug: the chip finishes without committing → the work exists only as an on-disk diff in that shared worktree.
3. #76681: no completion notification → the launching session is never told the chip finished, so no one knows to look.

Net: finished, uncommitted work, sitting in a worktree a different session is actively driving git against (and that the pool can reclaim), with no signal it exists. In our case it survived by luck; #77268/#74386/#74719 describe precisely the recycling/cleanup that would otherwise delete it.

Expected behavior

A spawned spawn_task session should not be able to terminate having silently orphaned finished work. Concretely: commit + push by default, or make "ended with a dirty worktree" an explicit, surfaced part of the chip's completion — so uncommitted results are never left without a signal.

Repro sketch

1. From a Desktop (local-agent-mode) session, produce a spawn_task chip whose prompt does not explicitly instruct it to commit its work.
2. Launch the chip; let its spawned session complete real file edits.
3. Observe: the spawned session ends with uncommitted changes in its worktree; the launching session receives no completion notification; nothing warns that the worktree was left dirty. The work is now discoverable only by manually inspecting the worktree.

Related

• #76681, #20754 — completion notification enqueued but never delivered (the "no signal" half; see my comment there for the notification data across four chips).
• #71773 — parent session cannot observe its spawned children.
• #77609, #75911 — worktree pool duplicate-allocation / premature reclaim (amplifiers).
• #77268, #74386, #74719, #68315, #70363 — worktree recycling / cleanup / checkpoint / destructive-git behaviors that destroy uncommitted worktree state (the downstream "how it's lost" half).

This report is deliberately scoped to the origin — the chip lifecycle manufacturing the uncommitted-and-unsignaled state — not a re-file of the destruction bugs above.