Stale/duplicate session titles + no wrong-session safeguard → silent data loss in Bypass-permissions mode

You've framed the real hazard correctly — "wrong-session + bypass-permissions," not the typo. One non-obvious thing worth knowing, because it lets you rebuild a safety net today without waiting on the retitle feature:
**Bypass-permissions disables the confirmation prompt, but it does not disable PreToolUse hooks.** Hooks fire independently of the permission mode. So the misrouted-destructive-command path that currently executes silently can still be intercepted deterministically by a hook — the one layer bypass mode doesn't skip.
Two concrete pieces:

1. Pin the session to its repo/branch and refuse mismatches. A SessionStart hook records the intended repo root + branch (e.g. into a per-session file keyed by the session id). A PreToolUse hook on Bash then, for destructive verbs (git commit, git push, git reset --hard, rm -rf, git checkout/branch switches), compares the current cwd repo/branch against what was pinned — and refuses (exit non-zero) on a mismatch. That converts "a misrouted command silently committed to the wrong repo" into a hard stop, even under bypass-permissions. Reads and matching-context commands pass, so it's low-friction.
2. Make sessions self-identifying despite drifted titles. A SessionStart hook that injects/echoes cwd + git branch + a short tag gives each session a stable, content-true marker in its own transcript, so you can tell "which session is this" from the session itself rather than from a title that froze on the first message. (A statusline showing repo/branch does the same on desktop.) This addresses the disambiguation half without needing the auto-retitle to ship.

The feature request (auto-retitle on topic drift + disambiguate near-identical titles + easy rename on mobile/desktop) is the right product fix — especially the mobile rename, since Remote Control is where misrouting is easiest. But the irreversible-write part of this is the more urgent half, and it's defensible at the hook layer right now: the title fix prevents misidentification, while a context-pinning PreToolUse guard prevents the destructive execution that misidentification leads to. Worth doing both — they cover different stages of the same failure.
(Reasoning from your description; you'd scope the refused-verb list and the "what counts as the right context" check to your own workflow — the point is just that the hook layer survives bypass mode, which is exactly the gap you hit.)

The framing is exactly right — the typo isn't the hazard, wrong-session + bypass-permissions is. A few user-side mitigations that contain the blast radius today, before any title/safeguard fix lands:
1. Isolate concurrent sessions by working directory, not just by title. Run each parallel session in its own git worktree (or clone):

git worktree add ../combo-lab-3d   feature/3d-lab
git worktree add ../combo-lab-infra infra/mcp

Now a misrouted command operates on that worktree's checkout — it can't overwrite files or commit on the sibling session's branch, because each session's cwd is a different tree. It turns "silent damage in the wrong repo" into "a no-op or obvious error in the right-but-wrong-task tree."
2. Treat --dangerously-skip-permissions as a per-task, single-session tool, not a default for long-lived or concurrent sessions. The flag's whole purpose is removing the confirmation that would otherwise catch a misroute; the more sessions you have live, the more that one prompt is worth. The infra/MCP session that had pivoted would, in normal permission mode, have surfaced the wrong-session command as a prompt instead of running it silently.
3. Keep a hook-level safety net that survives bypass mode. PreToolUse hooks run independently of the permission prompts, so they still fire under --dangerously-skip-permissions (this is exactly why hook-based guards are used in autonomous setups). A small PreToolUse hook that blocks (exit 2) destructive operations when the session isn't in its expected repo/branch — e.g. refuse git push / git reset --hard / rm -rf when git rev-parse --show-toplevel isn't the path this session is supposed to own — gives you a wrong-session guard that doesn't depend on the UI ever fixing titles. Encode the "expected repo" via an env var set when you launch each session.
None of these fix the underlying UX gap (stale titles + no wrong-session confirmation), but together they make a misroute recoverable instead of silent-and-irreversible.

Session identity belongs in the authorization context, not only in the UI label. A mutation decision should be bound to at least the canonical repo root, worktree, branch, session id, and the moment the operator last selected that session.

The proposed first-mutation-after-switching gate is especially useful because it creates an explicit handoff boundary. I would also show a stable short session id and cwd in every remote-control composer, then invalidate any cached mutation approval when either changes. Hooks can veto a dangerous command, but they cannot infer which similarly named session the human intended to address; that must be enforced above the tool layer.

Thanks — the wrong-session + bypass-permissions hazard is a fair point. Part of this is covered today: you can rename any session with /rename in the CLI, and renames made from the desktop app or claude.ai now sync to the CLI session name as well. Docs: https://code.claude.com/docs/en/commands

Automatically re-titling when the topic drifts, disambiguating near-identical titles, and a stronger mode indicator on mobile are still open, so leaving this open for those.

🤖 Generated with Claude Code