Problem
A session that drifts — keeps its pwd in worktree A but does real work in
worktree B via absolute paths — never marks B as in use. It's slightly
annoying but doesn't happen often, so this is a "park it and wait for more
signal" issue rather than something to act on now.
Why every current signal misses it
Both "in use" signals are anchored to where the session lives, not where
work happens:
- Live
/proc scan (session_linux.go) reads each claude process's
/proc/<pid>/cwd + open FDs. On drift the cwd stays at A, so the scan only
ever sees A. Open FDs could catch a B file, but edits open-and-close in
milliseconds and the scan would have to land in that window. The 30s tracker
decay only smooths a signal already caught — it can't catch one that was
missed.
.treetop-inuse marker, written only by the SubagentStart hook, uses
the payload cwd — also stale at A.
So this is fundamentally "work diverged from cwd," and we have no
activity-based signal to see it. Making the cwd scan smarter is a dead end —
the cwd genuinely doesn't move.
Candidate fix (for whenever we act)
An activity signal instead of a location one: a PreToolUse hook that
pulls the operative path out of the tool input (file_path for Edit/Write,
cwd/command for Bash), resolves its worktree via
git rev-parse --show-toplevel, and drops a PID-stamped marker there. The
existing marker machinery (PID liveness + 5-min TTL) handles cleanup, so it
slots into current infra.
Tradeoffs to weigh before building:
- Noise — a read-heavy pass (e.g. an Explore subagent grepping sibling
worktrees) would light them all up. Scope to mutating tools only
(Edit/Write, maybe Bash); skip pure reads. Even so, one stray edit marks a
worktree for ~5 min.
- Frequency — PreToolUse fires on every tool call vs. twice per subagent
today. Fast shell script, but a real jump in invocation count.
- Semantics — does a worktree touched once but not "lived in" count as in
use? For treetop's job (don't reap an active worktree / see what's live),
arguably yes, but it stretches the definition.
Suggested starting point if/when picked up: gate to Edit/Write first, add Bash
only if it proves necessary, and watch noise on read-heavy sessions.
Problem
A session that drifts — keeps its pwd in worktree A but does real work in
worktree B via absolute paths — never marks B as in use. It's slightly
annoying but doesn't happen often, so this is a "park it and wait for more
signal" issue rather than something to act on now.
Why every current signal misses it
Both "in use" signals are anchored to where the session lives, not where
work happens:
/procscan (session_linux.go) reads eachclaudeprocess's/proc/<pid>/cwd+ open FDs. On drift the cwd stays at A, so the scan onlyever sees A. Open FDs could catch a B file, but edits open-and-close in
milliseconds and the scan would have to land in that window. The 30s tracker
decay only smooths a signal already caught — it can't catch one that was
missed.
.treetop-inusemarker, written only by the SubagentStart hook, usesthe payload
cwd— also stale at A.So this is fundamentally "work diverged from cwd," and we have no
activity-based signal to see it. Making the cwd scan smarter is a dead end —
the cwd genuinely doesn't move.
Candidate fix (for whenever we act)
An activity signal instead of a location one: a PreToolUse hook that
pulls the operative path out of the tool input (
file_pathfor Edit/Write,cwd/command for Bash), resolves its worktree viagit rev-parse --show-toplevel, and drops a PID-stamped marker there. Theexisting marker machinery (PID liveness + 5-min TTL) handles cleanup, so it
slots into current infra.
Tradeoffs to weigh before building:
worktrees) would light them all up. Scope to mutating tools only
(Edit/Write, maybe Bash); skip pure reads. Even so, one stray edit marks a
worktree for ~5 min.
today. Fast shell script, but a real jump in invocation count.
use? For treetop's job (don't reap an active worktree / see what's live),
arguably yes, but it stretches the definition.
Suggested starting point if/when picked up: gate to Edit/Write first, add Bash
only if it proves necessary, and watch noise on read-heavy sessions.