[Feature Request] Safety guardrails for destructive git ops in shared worktrees with concurrent Claude sessions

Problem

Multiple concurrent Claude Code sessions sharing the same git working tree can silently overwrite each other's uncommitted changes via destructive git operations (stash, reset --hard, clean -fd). Detection happens only after-the-fact via re-Read showing reverted content.

Evidence

Real incident (single operator account, single project, multiple Claude Code sessions concurrent):

• 5 audit-trail working dirs LOST (untracked + uncommitted; never recoverable from git history)
• Registry yaml file reverted ~2x mid-session (required Edit re-application)
• 12+ parallel-agent commits during 1 active session in the same working tree
• Recovery via transcript reconstruction + structural process change (per-session git worktree SOP)

Forensic detail: stash@{0} contained 21 files including a 67-line registry yaml diff; git reflog -30 showed 6 reset: moving to HEAD entries (working-tree reset = uncommitted-change discard).

Proposed feature: safety guardrails (PRIMARY scope)

Three concrete protections:

1. Detect another active session on the same worktree via tool-managed session lease/heartbeat with expiry. NOT a simple lockfile (stale locks would create false positives + operator bypasses; tool-managed lease handles expiry + cleanup automatically).

1. Refuse OR require explicit re-approval before git stash, git reset --hard, OR git clean -fd when uncommitted changes would be lost. Detection: tool inspects working tree state pre-operation; if uncommitted changes exist that the destructive op would discard, prompt operator OR refuse with explanation.

1. Warn when the worktree/index changed unexpectedly since the session's last known state. Detection: tool maintains a session-scope view of git status --porcelain snapshot; on next destructive-or-mutating op, compare against snapshot; warn on unexpected diff.

Future direction (separate follow-up scope)

Default to per-session git worktree isolation when starting work in a shared multi-writer repo. Track separately to avoid scope-creep on this primary issue. Per-session worktree isolation is the structural fix; safety guardrails (this issue) are the immediate harm-reduction layer.

Workaround until feature ships

Per-session git worktree isolation per a local SOP (one-writing-session-per-worktree policy added to project CLAUDE.md).

Severity

HIGH (silent data loss in multi-session workflows). Multi-session is increasingly common as Claude Code adoption grows; ANY operator running 2+ concurrent Claude Code instances on the same repo is vulnerable.