fn print_dev_instance_collision(
channel: &str,
data_dir: &Path,
socket_path: &str,
)Expand description
User-facing message for an actual second-instance collision (not a
bind-failure, not a stale socket — a real running launcher answered our
connect probe). Shared by both call sites in
bind_socket_with_recovery (fast-path and post-recovery-lock retry),
which previously duplicated this message and both got it wrong the same
way — see docs/specs/SPEC_DEV_INSTANCE_ISOLATION_DIAGNOSTICS_2026_09_19.md.
For a dev- channel, this used to say “Use task dev:local to launch a
second isolated session” — plausible-sounding, and wrong for the common
case. task dev:local’s version bump only changes the launcher’s own
IPC socket key (hash.rs’s data_dir_hash16, keyed on
CARGO_PKG_VERSION/AGENTMUX_BUILD_LABEL at compile time) — it does
NOT change the CEF profile/data directory, which for dev mode is keyed
on (branch, clone_id) — NOT version — via
crates/common/src/data_paths.rs’s resolve_channel_and_dir
(honor_env_channel=false for dev launches). clone_id
(runtime_mode.rs’s derive_clone_id) is a hash of the CLONE’S OWN
CANONICAL WORKSPACE-ROOT PATH — git-worktree-aware by design, so a
second worktree of the SAME branch already gets a distinct clone_id
and therefore a distinct data dir, with no branch switch needed;
resolve_channel_and_dir folds both into the one channel string this
function receives (format!("dev-{branch}-{clone_id}") — confirmed by
reading that call site directly). Two dev instances collide on CEF’s
own SingletonLock only when BOTH branch and clone/workspace path are
identical — reproduced live: a real rebuild under a bumped version, run
from the unchanged clone path on the unchanged branch, got a new
launcher socket and STILL hit CEF early exit (process singleton or similar) on the unchanged data dir. The fix is a different branch OR a
different clone/worktree path (either one changes channel) — named
directly here instead of pointing at a command that cannot solve this
specific problem. (ReAgent P1 on this PR: an earlier revision of this
message claimed branch was the ONLY lever, which is what this revision
corrects — verified against resolve_channel_and_dir’s actual source,
not just re-asserted.)