fix(cursor): ignore orphaned crashpad helpers when detecting a running Cursor - #1
Merged
Merged
Conversation
cursorIsRunning matched any process under /Applications/Cursor.app/Contents/, which includes chrome_crashpad_handler. Those helpers are reparented to launchd and survive the app, so a single stale one made init/sync/install permanently report Cursor as running. Match the main binary instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
ocx-cursor initfails witheven when Cursor is fully quit — and it never recovers, no matter how many times you quit and relaunch.
Cause
cursorIsRunning()matches any process under/Applications/Cursor.app/Contents/:That pattern also matches
chrome_crashpad_handler, Electron's crash reporter. Crashpad handlers are reparented tolaunchd(PPID 1) and can outlive the app, so one stale handler makes the check returntrueforever.On my machine, with Cursor fully quit:
All five are orphans; no
Contents/MacOS/Cursorand noCursor Helperprocess exists. Two date back to July 14, and their--annotation=_versionvalues (2.0.43,3.11.19) point at Cursor builds that are no longer installed. Once these accumulate, the check is stuck until reboot.Fix
Match the main binary instead of the whole bundle. Helpers only run while the main process is alive, so this stays correct for the real "Cursor is open" case:
init,sync, andinstallall route throughcursorIsRunning(), so this covers all three paths.Verification
npm test— 41/41 passnpm run check— passcursorIsRunning()returnsfalsewith all five orphaned crashpad handlers still runningI have not exercised the Cursor-is-open path on this branch, so that's worth a second pair of eyes.