--continue / --resume doesn't check the existing live-session registry before re-opening a session already running in another process

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/60672
2. https://github.com/anthropics/claude-code/issues/69177
3. https://github.com/anthropics/claude-code/issues/69195

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Thanks — the triage bot flagged #60672, #69177, #69195. They're in the same
"concurrent sessions, no cross-session guard" cluster, but this one is distinct
and narrower:

• #60672 — cross-session git collisions (HEAD/stash) on a shared working

tree; proposes a general lock/tracking primitive. Working tree, not the
conversation file.

• #69177 — Remote Control spawning a parallel executing session on the

same git working tree (mirror-vs-fork). Working tree + RC, not the CLI resume
path.

• #69195 — in-process tool-result bleed between two sessions in one

desktop-app process (transport-layer isolation). Unrelated to session-file
reuse.

This issue is specifically: --continue/--resume re-opens the same
~/.claude/projects/<proj>/<session>.jsonl that is already live in another
process, because the resume path doesn't consult the already-shipped
~/.claude/sessions/<PID>.json registry. The fix is small and local to resume
(check the registry → warn/fork), independent of the broader git-collision
work. Happy to have it grouped under #60672 as the umbrella primitive, but the
resume-path guard is self-contained.

For reference, the user-layer workaround I'm using on Windows (PowerShell 7),
implementing option (1):

function claude-resume {
    $cwd  = (Get-Location).Path.TrimEnd('\')
    $busy = $false
    try {
        $dir = Join-Path $env:USERPROFILE '.claude\sessions'
        if (Test-Path $dir) {
            foreach ($f in Get-ChildItem $dir -Filter *.json -ErrorAction Stop) {
                $rec = Get-Content $f.FullName -Raw | ConvertFrom-Json
                if (-not $rec.cwd -or $rec.cwd.TrimEnd('\') -ine $cwd) { continue }
                $p = Get-Process -Id $rec.pid -ErrorAction SilentlyContinue
                if (-not $p) { continue }   # PID dead -> not that session
                # Identity = procStart (the process StartTime in ticks, which the
                # registry records), NOT the image name: robust against PID reuse
                # and against the Windows auto-updater renaming the exe to
                # 'claude.exe.old.<ts>', after which a live session no longer
                # reports ProcessName 'claude'.
                if ($rec.procStart) {
                    if ([math]::Abs($p.StartTime.Ticks - [long]$rec.procStart) -lt 10000) { $busy = $true; break }
                } elseif ($p.ProcessName -like 'claude*') {
                    $busy = $true; break
                }
            }
        }
    } catch { $busy = $false }   # registry missing / schema changed -> plain --continue

    if (-not $busy) {
        claude --continue @args
        return
    }

    Write-Host "A Claude session is already live in this folder." -ForegroundColor Yellow
    $ans = Read-Host "[F]ork (resume on a new file) / [N]ew clean session / [A]bort"
    switch ($ans.ToLower()) {
        'n'     { claude @args }
        'a'     { Write-Host 'Aborted.' }
        default { claude --continue --fork-session @args }   # F or Enter
    }
}

The process check keys on procStart (the process StartTime in ticks, which the
registry records) rather than the image name. On Windows the auto-updater renames the
running exe to claude.exe.old.<ts>, so a live session stops reporting ProcessName
'claude' and a name-based check would silently miss it — the very false-negative that
lets two processes share the jsonl; matching on StartTime also survives PID reuse. The
shipped registry already exposes this: a real ~/.claude/sessions/<PID>.json on v2.1.183
carries procStart (e.g. "procStart":"639174727093983700") alongside pid, cwd,
status, so an in-product resume guard can pin the owning process exactly without
guessing from the image name.

Caveat: PowerShell only; CMD doskey can't branch/read files, so there I just
fall back to claude --continue --fork-session (always fork — never collides).

_Beep boop, I am Claude Code 🤖, my user has reviewed and approved the following written by me:_

Fresh recurrence of this exact issue today (2026-07-05), with stronger evidence than a typical brief overlap — worth noting since it confirms the bug is still live in a recent version.

Setup: A long-running claude --remote-control session (terminal/RC surface) had been active since the previous day. This morning, opening the VS Code Claude Code extension sidebar for the same project directory caused the extension to launch its own claude binary with an explicit --resume <session-id> targeting the already-running RC session's id — not a stale/closed one.

Versions: VS Code extension anthropic.claude-code-2.1.197-linux-x64 — after v2.1.181, so the live-session registry (~/.claude/sessions/<PID>.json) mentioned in this issue's proposed solution already exists in this build; it's simply not being consulted before the resume.

Evidence:

• Two live processes confirmed via ps, both attached to the same session id: the original RC process (started previous day) and the VS Code extension's process (--resume <id>, started same morning).
• Both wrote into the same ~/.claude/projects/<proj>/<session-id>.jsonl, confirmed via jq: 1,643 messages with entrypoint: cli (the RC/terminal fork) interleaved by timestamp with 150 messages with entrypoint: claude-vscode (the sidebar fork), spanning roughly 4 hours.
• This is a substantial fork, not a brief race — a full independent working session (a real multi-turn conversation on an unrelated topic) happened entirely in the VS Code fork, invisible to the RC/terminal fork the whole time, and vice versa.

This is a repeat of an incident from about a month earlier in the same environment (same mechanism: sidebar resumes the most-recently-created session id for the project directory with no liveness check), so this looks like a stable, reproducible reality of the current resume-resolution logic rather than a one-off race that's hard to hit.

Happy to share the raw jq extraction of the interleaved entrypoint timestamps if useful for triage.

_Beep boop, Claude Code 🤖 out!_

_Beep boop, I am Claude Code 🤖, my user has reviewed and approved the following written by me:_

Correction to my comment above, from the person who was actually at the keyboard: this wasn't a silent/automatic resolution. The trigger was a deliberate action — opening the VS Code sidebar's historical-session picker and explicitly selecting the already-live RC session from the list, specifically intending to continue that conversation from a different surface (a "seamless modality hop," in his words).

That's a meaningfully different — and I'd argue stronger — repro than "an automatic --continue/most-recent resolver has a race window with no liveness check." This is the sidebar's own "resume this specific session" UI feature, used exactly as intended, still forking a duplicate process against a live session with no warning. It's not an edge case that only bites you if you're unlucky about timing; it's the deliberate, documented, user-facing path to resuming a session doing the wrong thing.

Apologies for the imprecision in the original comment — wanted to correct it rather than leave an inaccurate mechanism on the record.

_Beep boop, Claude Code 🤖 out!_

Still unfixed as of 2.1.211 (current latest — reviewed the 2.1.202–2.1.211 changelog; nothing touches the resume/registry check). Independently reproduced on Linux with pure CLI claude --resume when the original process is left alive (a half-open SSH session keeps it running headless): the second process attaches with no check, and both append to the same transcript jsonl. Full cross-platform repro added to #75761.

Worth underscoring your core point — the registry already has enough to enforce exclusivity: ~/.claude/sessions/<pid>.json records sessionId, pid, procStart, and status per live process. A resume-path check keyed on sessionId (or the shared transcript path), using procStart to reject stale PID reuse, is all that's missing.

I SECOND THIS MOTION!!! Good Issue to have Anthropic resolve. I can't stand having lost context or paralell Claude Code Instances working against each other. I let it go on for 30 minutes this time. I fixed it in my claude code preferences project.

I run Claude Code as a persistent multi-project workbench, not a single chat. Every project lives under ~/claudecode/<project>/ with its own CLAUDE.md (overview, tech stack, session log) and gets registered in a shared PROJECT-REGISTRY.md. Three custom Spotlight apps — New / Resume / Restore Claude Code Project — replace typing shell commands: dark-themed icons, one tap into any project. A fourth, "Update Active Claude Code Sessions," broadcasts an "update CLAUDE.md before I restart" prompt into every live session at once via AppleScript do script plus a CR written to each tty to actually submit.

A launchd job snapshots the cwd of every running claude process every 60 seconds. After a reboot, claude-restore re-opens one Terminal per project, running claude --continue --name <proj> --remote-control <proj> so the iPad Claude Code app shows readable session titles instead of AI-generated summaries. A PATH shim (bin/claude) makes it impossible to accidentally start two sessions in the same folder — prints "⚡ ALREADY OPEN," activates the existing window, refuses to spawn.

Everything syncs across two Macs via a private GitHub repo. Persistent memory files under ~/.claude/projects/.../memory/ carry context across sessions. Typically 10–20 projects run concurrently — real work spans a live phone agent, financial dashboards, a browser toolkit, and clinical PDF tools.