Skip to content

Auto-cleanup of stale owners, inactive members, and old notes #27

Description

@mostlydev

Problem

Long-lived rooms accumulate cruft that newer sessions have to step around:

  • Stale owners. A room can sit in owner_gone state with the listed owner being a process that exited days ago (e.g. an inactive codex:d4bc2492 from 2 days ago still listed as owner in the workspace room today). Every new agent that joins has to issue an explicit tt take --reason owner_gone just to start work.
  • Inactive members. members[] keeps every harness session that has ever joined, even when their status has been inactive for many hours. tt state becomes noisy; identifying "who is actually here right now" requires filtering by status === "active" on the client.
  • Old notes. Notes from prior unrelated tasks persist forever (no resolved_at set, no auto-expiry). New owners reading tt notes list to find context for their turn have to wade through historical notes from features that shipped weeks ago.

What "active cleanup" could look like

Sketch — exact policy TBD:

  1. Auto-release stale ownership. When a room transitions to owner_gone and the lease expires (or the owner's process has been gone for > N * heartbeatIntervalMs), automatically clear the owner field rather than leaving it pinned. Next claim is a fresh sequence-path claim, no tt take needed.
  2. Inactive-member pruning. Drop members from members[] (or hide by default in tt state) once their last_seen_at is older than some threshold (e.g. presenceTtlMs * 2, currently 8 h). Keep the historical record in events; just stop surfacing them in the current state projection.
  3. Note TTL or scoped notes. Either: (a) auto-resolve notes after idleNoteTtlMs, (b) tie notes to a specific turn / task and hide resolved ones by default in tt notes list, or (c) both. Add a --include-resolved / --include-old flag for explicit recall.

Why now

  • tt list showing weeks-old owner fields confuses new operators about whether the room is occupied.
  • A clean tt state is part of the adoption story — every doc screenshot will show whatever junk is in the room.
  • This came up while a fresh task was starting in a room that had a 4-day-old stale owner from an unrelated task, and ~30 notes from finished features.

Out of scope (separate issues if needed)

  • Hard-deleting events/history.
  • Cross-room cleanup tooling.
  • Changing the membership model itself.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions