Archiving a branch does not reap its Docker dev-env container → orphaned containers leak RAM/disk

[sadpandajoe]

Summary

Archiving an Agor branch does not reliably stop/remove its Docker dev-env container. The branch row is archived and its worktree is cleaned from disk, but the compose containers keep running indefinitely — orphaned, consuming RAM and disk with no branch behind them.

This contradicts the documented behavior of agor_branches_archive ("Stops the environment if running, optionally cleans or deletes the filesystem…").

Evidence (live examples found 2026-07-30 on agor-2 / agor.sandbox.preset.zone)

Branch	Archived	Worktree	Container	Container status
review-apache-superset-42090 (apache/superset)	2026-07-16 (fs deleted)	cleaned 1M stub	review-apache-superset-42090-db-light-1	Up 2 weeks
audit-config-yaml-tenant-settings (preset-io/agor)	fs cleaned stub	1M stub	agor-audit-config-yaml-tenant-settings-agor-dev-1	Up 6 days

Both branches were archived and their worktrees removed, yet the containers (plus their named volumes and compose networks) survived. They were only discovered because the shared box hit 94% disk and the 4x/day "Dev-Env Watchtower" ops agent flags stale containers by raw docker ps.

Detection signature used: a running compose container whose com.docker.compose.project.working_dir points at an Agor worktree path that is now gone or a cleaned stub.

Impact

• RAM/disk leak that accumulates silently; on agor-2 there are ~450 worktree dirs under the agor repo alone and the box sits at 93–94% disk.
• The Dev-Env Watchtower is currently a band-aid reaping these on a schedule; the platform should not depend on it.

Likely root cause

agor_branches_archive (and/or the env-stop path it calls) does not guarantee docker compose down / container+volume+network teardown completes before/independent of the worktree cleanup. If the worktree is deleted first, the compose file is gone and any later teardown attempt can't find it, leaving the container running. Needs tracing in the environment/daemon lifecycle code.

Proposed fix

1. Archive must reap the container reliably — tear down the env (containers + project volumes + network) before deleting the worktree, and make it idempotent / not silently swallow failures. Track container/project identity independent of the on-disk compose file so teardown works even if files are already gone.
2. Idle-env reaper backstop — a daemon sweep that stops dev-envs whose branch/session has been inactive beyond a configurable threshold, and that kills containers whose backing branch is archived/deleted. This absorbs the class of leak generally, not just the archive path.
3. Consider a startup/periodic reconciliation: for every running *-*-light/agor-dev compose project, if its working_dir worktree is gone or the branch is archived → reap.

Repro

1. Create a branch with a dev-env, start the env (containers come up).
2. Archive the branch (with filesystem cleanup).
3. docker ps — the container is still running despite the branch/worktree being gone.

Notes

• Immediate cleanup already performed for the two examples above (containers + volumes + networks removed), reclaiming ~4 GB.
• Reported via the Agor assistant while debugging a user's "I archived it but the env kept running" report.