[BUG] --resume while the original process is still alive → two live processes of one session act on the repo concurrently (orphaned twin keeps working headless)

Independent reproduction on Linux + pure CLI (no VS Code / extension host), confirming this isn't extension-specific and still occurs on the latest release.

Environment: Claude Code CLI 2.1.201; also reviewed the changelog through 2.1.211 (current latest) — no fix touching session locking, concurrent resume, or transcript ownership.

Different trigger, same outcome — a half-open SSH session:

1. Start an interactive claude over SSH; leave it idle at the prompt (process alive).
2. The SSH connection drops but stays half-open (no dead-client detection) → the pty and the claude process survive.
3. Reconnect and claude --resume <id> (or --continue) → no warning; a second live process starts under the same session id.
4. Both processes append turns to the same ~/.claude/projects/<project>/<id>.jsonl and run tools against the same working tree. Also reproduces with the original still alive mid-turn.

So the orphaning path isn't limited to VS Code extension restarts — any client death that leaves the process alive (dropped SSH, detached tty) reaches the same "two executors, one transcript" state.

This lines up with #69364: the live-session registry at ~/.claude/sessions/<pid>.json already records sessionId, pid, procStart, and status per live process — everything a resume-path exclusivity check would need — but --resume/--continue doesn't consult it before attaching. A pidfile/lock check keyed on the shared transcript path (both processes write one jsonl), using procStart to guard against PID reuse, would close it.

The fact that resuming a session while the original is still alive can create two live processes working on the same repo (and both writing to the transcript) is nasty. You end up with duplicate commits and conflicting state with no clear way to see what’s happening.

We’ve been treating session identity and exclusivity as important because once you have autonomous work happening in the background, this kind of collision becomes really expensive.

You hit this one yourself or just saw the report?
https://github.com/keesan12/martin-loop

This is not stale, it just burned me. Session started in herdr, then exited, then later resumed on bare shell. Next morning, restarted herdr for other reasons, didn't realize this session also resumed in the background. Another agent awoke the zombie via SendMessage; cue the split-brain shenanigans for another hour+ of confusion before the root cause was discovered and neutralized. So stupid, claude-code should easily be able to lock a session-id for single-writer protection.

Until --resume refuses (or prompts) on a session id that is already held, here is an interim hook (written by Claude Opus 5) that at least makes the duplicate harder to miss. Because the hook doesn't execute until you've typed something, you only get the warning one command in — still, better than nothing. While this version is aimed at Linux, the notes describe the key tweak that Macos will need; ask your own ℄ to adapt it.

---

It needs no lock of its own, so it has no stale-lock failure mode: Claude Code already writes ~/.claude/sessions/<pid>.json containing {pid, sessionId, procStart, ...}, and reading that answers the question directly.

~/.claude/hooks/session-start-double-resume.sh, chmod +x:

#!/usr/bin/env bash
set -uo pipefail

# A hook runs a few processes below claude, so $$ is not the session's pid.
ancestors() {
  local p=$$ ppid
  while [ "$p" -gt 1 ]; do
    printf '%s\n' "$p"
    ppid=$(awk '{print $4}' "/proc/$p/stat" 2>/dev/null) || return 0
    [ -n "$ppid" ] || return 0
    p=$ppid
  done
}

sid=$(jq -r '.session_id // empty' 2>/dev/null) || exit 0
[ -n "${sid:-}" ] || exit 0
mine=" $(ancestors | tr '\n' ' ')"

for f in "${CLAUDE_CONFIG_DIR:-$HOME/.claude}"/sessions/*.json; do
  [ -e "$f" ] || continue
  # One field per line, not @tsv: bash collapses runs of tabs whatever IFS says,
  # so a missing procStart would shift sessionId into its place.
  mapfile -t fld < <(jq -r '(.pid|tostring),(.procStart//""),(.sessionId//"")' "$f" 2>/dev/null)
  [ "${#fld[@]}" -eq 3 ] || continue
  pid=${fld[0]}; recorded=${fld[1]}; held=${fld[2]}
  [ "$held" = "$sid" ] || continue
  [ "${mine#* "$pid" }" = "$mine" ] || continue
  # awk exits non-zero on a dead pid; field 22 is the process start time, so a
  # recycled pid cannot pass as the holder.
  actual=$(awk '{print $22}' "/proc/$pid/stat" 2>/dev/null) || continue
  [ -z "$recorded" ] || [ "$actual" = "$recorded" ] || continue
  echo "This session is ALREADY OPEN in pid $pid. Two live processes on one session interleave writes to its transcript and act independently. Tell the user, and do nothing else until they have quit one."
done

In ~/.claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$HOME/.claude/hooks/session-start-double-resume.sh\"",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

Gotchas, all measured rather than assumed

• You will see nothing when you resume. A SessionStart hook cannot write to the terminal — I captured a real interactive resume under a pty and tried plain stdout, {"systemMessage": ...} and stderr; none of them renders. The text goes into the model's context, so the warning surfaces on your first message. Asked an unrelated question, the resumed session opened with "⚠️ Heads-up before anything else: … this session is already open in another process (pid 451845) … I'll hold off on anything touching the repo until you've closed the duplicate." That is still before any work happens, but it is not a banner at resume time, and no hook can be one.
• The matcher must be resume. A fresh claude gets a new session id and cannot duplicate one, so wiring this to startup means it never fires in the only case it exists for. --resume reports source: "resume"; I did not test --continue, so widen to "startup|resume" if in doubt — it is silent whenever the session is held once, so a wider matcher costs nothing.
• Key on session id, not project. If you run several sessions per repo, a per-project check fires on nearly every launch and gets ignored.
• Linux only as written. Both walks read /proc; on macOS they become ps -o lstart=,ppid=.
• Testing it from another claude will mislead you. A nested claude inherits CLAUDE_CODE_CHILD_SESSION, which turns transcript saving off and writes no ~/.claude/sessions entry at all — so the process you spin up as the "other window" is invisible to the hook and it correctly stays silent. env -u CLAUDE_CODE_CHILD_SESSION first, or just open a second terminal.

What was verified

Against fabricated registries and a live one: a live duplicate warns; own session, dead pid, recycled pid (procStart mismatch), a different session id and unparsable entries are all silent; and an unparsable entry does not mask a real duplicate sorting after it. Deleting any one of the four guards changes one of those outcomes.

It then caught a genuine double on its first real encounter, which is the only test I fully trust.

Appendix: why the lock-file approach in #35719 does not fire

Worth recording only because it is the workaround people will find first, and its failure is silent in the worst direction — you install it, see no warnings, and conclude you have not hit the bug. (#35719 is closed NOT_PLANNED and locked, so this cannot be said there.)

It ends with echo "$$" > "$LOCK_FILE" and checks later with kill -0 "$OTHER_PID". But a hook does not run as the claude process — it runs in a short-lived shell a few levels below it, which exits when the hook returns. So the recorded pid is dead before any later session reads it:

hook subshell $$            = 362385
nearest claude ancestor pid = 314695

hook process recorded pid : 362936
  kill -0 362936 -> DEAD   => the warning never fires

Its companion unlock hook compares $(cat "$LOCK_FILE") against its own $$, a different shell again, so the comparison never matches and the stale lock is never removed either.

That is the whole reason the hook above walks the ppid chain rather than trusting $$, and reads Claude Code's own session registry rather than keeping a lock.