[Bug] Update process leaves stale lock file, blocking subsequent updates

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13085
2. https://github.com/anthropics/claude-code/issues/13653
3. https://github.com/anthropics/claude-code/issues/13599

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

My issue is updating, not installing. And on Mac, not linux

Same issue on Mac. Was trying to update to 2.0.65. Thanks @graham-u for the delete lock files tip!

had the same issue on Ubuntu also,
once when trying to update to 2.0.65
and again when trying to update to 2.0.68
had to delete .local/state/claude/locks/*.lock files to resolve , tried also reboot before that - didn`t resolved until .lock files were deleted

had the same issue on Ubuntu also, once when trying to update to 2.0.65 and again when trying to update to 2.0.68 had to delete .local/state/claude/locks/*.lock files to resolve , tried also reboot before that - didn`t resolved until .lock files were deleted

This worked for me. Thanks.

Happened to me, ran ~/.local/share/claude/versions/2.0.74 and rm -rf ~/.local/state/claude/locks/2.0.74.lock and then claude update and the update worked.

Comment written by Claude with info I gave it:

---

This issue also affects fresh installations via the documented install method:

curl -fsSL https://claude.ai/install.sh | bash

The --force workaround cannot be passed through this method, leaving users completely stuck without manually discovering the undocumented ~/.local/state/claude/locks/ directory.

Video showing the issue:

https://github.com/user-attachments/assets/b67b060c-a3a1-4ff1-8c99-cd079dc80cd9

---

The core problem: Lock files are empty directories with no PID tracking. There's no way to detect if a lock is stale.

~/.local/state/claude/locks/
└── 2.0.76.lock/   # Empty - no PID to validate

Issues #14301 and #13599 were closed without fixing this. Users are told to rm -rf the locks directory, which is unsafe if Claude actually is running.

Standard fix - store PID in lock file and validate on acquisition:

if [ -f "$LOCK_FILE" ]; then
    lock_pid=$(cat "$LOCK_FILE")
    if kill -0 "$lock_pid" 2>/dev/null; then
        echo "Already running (PID: $lock_pid)"; exit 1
    fi
    rm -f "$LOCK_FILE"  # Stale, clean up automatically
fi
echo $$ > "$LOCK_FILE"
trap "rm -f '$LOCK_FILE'" EXIT

This eliminates the need for --force entirely and handles crashes gracefully.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

There was a partial fix with --force not working here:
https://github.com/anthropics/claude-code/blob/2bc62d1456e3b3084bb8c7971a8b111ebe5f505d/CHANGELOG.md?plain=1#L556

But as mentioned above that doesn't work with the install method, so it is not clear from the changelog if this has been fixed as I haven't seen anything else which suggests it is.

I think it is a mistake to close this before there is some confirmation that an old lockfile won't block the previously mentioned install method.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.