Summary
A crewmate's tmux window is named fm-<id> at spawn, and the task's
state/<id>.meta records window=<session>:fm-<id> (a session:window-NAME target). But on
setups where the shell prompt renames the window every command (e.g. a Starship/zsh precmd
that calls tmux rename-window to show the repo + git status), the fm-<id> name is
clobbered — the window becomes e.g. tkt-env#tkt-env. After that:
fm-peek / fm-send / fm-watch can no longer resolve the window by the meta name
(can't find window: fm-<id>), so stale-pane detection silently breaks (status-file and
turn-end wakes still work, so it's not total, but pane peeking/steering is lost).
- FirstMate-managed worktrees become visually indistinguishable from the user's own
worktree windows.
allow-rename off and automatic-rename off do not prevent this — they only block
escape-sequence (OSC) renames, not an explicit tmux rename-window issued by a shell hook.
Reproduction
- Spawn a crewmate (tmux backend) on a machine whose shell prompt renames the window in a
precmd hook.
- After the crewmate's shell runs its prompt once,
tmux list-windows shows the window
renamed away from fm-<id>.
bin/fm-peek.sh fm-<id> → error: no window named ....
Root cause
Meta targets the window by its mutable name. Names are not a stable handle when anything
else can rename the window.
Suggested fix
Record the stable tmux window-ID in meta instead of (or in addition to) the name — e.g.
window=<session>:@<window-id> (verified: <session>:@NN resolves through
fm_backend_resolve_selector, while a bare @NN does not). Window-IDs never change for the
life of the window, so every supervision path stays resolvable regardless of renames.
Optionally, also keep a short distinguishing name convention (e.g. fm.<repo>#<issue>) so
FirstMate worktrees are visually separable from the user's own — but that is cosmetic; the
ID-based target is the correctness fix.
🤖 Claude Code · claude-opus-4-8 · 2026-07-15
Summary
A crewmate's tmux window is named
fm-<id>at spawn, and the task'sstate/<id>.metarecordswindow=<session>:fm-<id>(a session:window-NAME target). But onsetups where the shell prompt renames the window every command (e.g. a Starship/zsh
precmdthat calls
tmux rename-windowto show the repo + git status), thefm-<id>name isclobbered — the window becomes e.g.
tkt-env#tkt-env. After that:fm-peek/fm-send/fm-watchcan no longer resolve the window by the meta name(
can't find window: fm-<id>), so stale-pane detection silently breaks (status-file andturn-end wakes still work, so it's not total, but pane peeking/steering is lost).
worktree windows.
allow-rename offandautomatic-rename offdo not prevent this — they only blockescape-sequence (OSC) renames, not an explicit
tmux rename-windowissued by a shell hook.Reproduction
precmdhook.tmux list-windowsshows the windowrenamed away from
fm-<id>.bin/fm-peek.sh fm-<id>→error: no window named ....Root cause
Meta targets the window by its mutable name. Names are not a stable handle when anything
else can rename the window.
Suggested fix
Record the stable tmux window-ID in meta instead of (or in addition to) the name — e.g.
window=<session>:@<window-id>(verified:<session>:@NNresolves throughfm_backend_resolve_selector, while a bare@NNdoes not). Window-IDs never change for thelife of the window, so every supervision path stays resolvable regardless of renames.
Optionally, also keep a short distinguishing name convention (e.g.
fm.<repo>#<issue>) soFirstMate worktrees are visually separable from the user's own — but that is cosmetic; the
ID-based target is the correctness fix.