---
title: "Your Daily Cleanup Shouldn't Commit Other Sessions' Work"
canonical: https://dxdev.com/blog/2026-09-26_nightly-sweep-multi-session/
datePublished: 2026-09-25
---
The overnight work log for one night shows more than 50 headless `claude -p` sessions between 12:09 and 4:07 AM. Three different agent roles, a secretary, a system manager and a task manager, were handing the same "mute my pc" unit back and forth. At 2:12 one session closed without running `/close` and left its unit open. Our nightly cleanup runs into a repo like that, and until recently it had one behavior: commit everything.

## A sweep that assumed one writer

The sweep ran `git add -A` and `git commit` in every repo it found dirty. It treated the working tree as if a single writer owned it. That was fine when it was true. Now several sessions edit one repo at once, and any of them can be mid-edit when the sweep arrives.

So the sweep would find a half-written file, commit it, and the log would say I wrote it. The session that owned the file kept editing, and its next diff was against a commit it never made. Nothing crashed. The history just recorded unfinished work as finished, under my name, at an hour when nobody was reviewing anything.

I kept that in production longer than I should have because the failure was quiet. A commit that says "checkpoint" looks tidy. You only notice when you try to work out why a file's history shows a state that never existed on purpose.

## Holding what a live session owns

The fix is a commit titled "checkpoint sweep holds files a live session owns instead of committing them". The sweep now checks whether a live session owns files in a repo before it touches anything. If one does, it leaves those files alone and reports them instead of committing.

A repo with no live session gets the same treatment as before. The cleanup still does its job on the quiet repos, so nothing is lost there.

## Counting one folder several times

Deciding "is a session live" means reading session transcripts, and the next commit was about that: "scan each transcript root once when seat dirs are junctions to one folder". Several seat directories are junctions pointing at a single folder, so walking each seat separately read the same transcripts several times over. The duplicated scan did not change the verdict, but it multiplied the work. Resolving the roots and scanning each real folder once fixed it.

## Why the log makes the case

Look at how that one night's log reads. Many short sessions overlap. The `OK` responses from the secretary role land between 2:47 and 3:26, a few minutes apart. Close lines show up for sessions that ended without a proper close. In that environment "nobody is editing right now" is almost never true. A sweep that assumes it will sooner or later commit something someone is holding open.

The rule now is that the sweep only commits work it can show has no owner. When it can't show that, it says so and leaves the files alone. A wrong commit under my name is much harder to untangle than a repo that waited until morning.