feat(boot): auto-heal stale boot registration on supervisor startup

[gaojunran]

Problem

When the binary path changes after a package-manager upgrade (e.g. brew cleanup, mise install), the launchd plist or systemd unit still points to the old version-specific path, causing the supervisor to fail on next boot with EX_CONFIG (78) on macOS or a missing binary on Linux.

See discussion #544 for details.

Solution

On supervisor startup, check whether the registered boot binary path matches the current PITCHFORK_BIN. If stale, re-register with the current path.

This runs in a background spawn_blocking task and is best-effort: errors are logged and swallowed, never blocking startup.

Changes

• Cargo.toml: upgrade auto-launcher from 1.0.3 to 1.1
• src/boot_manager.rs: add check_and_reregister_if_stale() which reads the registered path back from disk via auto_launcher::AutoLaunch::get_registered_app_path() (new in 1.1), compares to PITCHFORK_BIN, and re-registers by disable() + enable() when stale
• src/supervisor/mod.rs: call the check in Supervisor::start() via tokio::task::spawn_blocking, fire-and-forget

Why not just use a stable path?

mise shims are shell scripts that require MISE_* environment variables which launchd/systemd minimal environments cannot provide. Detect-and-re-register avoids this issue entirely and works across all package managers.

auto-launcher dependency

This PR requires auto-launcher 1.1, which adds get_registered_app_path() — a new API that reads the binary path back from the on-disk launch file (plist/systemd unit/registry). See auto-launcher PR #7.

Closes #544

AI-assisted — Tool: opencode; model: astra/glm_5d2_fp8_code; version: unavailable.

Summary by CodeRabbit

• Bug Fixes

  • Improved boot registration reliability by automatically detecting and correcting outdated launcher paths.
  • Boot registration issues are handled gracefully without interrupting application startup.

• Maintenance

  • Updated the automatic launch support to a newer version.

[coderabbitai]

📝 Walkthrough

Walkthrough

The update adds stale boot-registration recovery. BootManager compares the registered path with PITCHFORK_BIN, and Supervisor runs the check asynchronously during startup. The auto-launcher dependency requirement changes from 1.0.3 to 1.1.

Changes

Boot registration recovery

Layer / File(s)	Summary
Stale path detection and re-registration Cargo.toml, src/boot_manager.rs	The auto-launcher requirement changes to 1.1. BootManager detects stale paths and re-registers the current launcher.
Non-blocking startup integration src/supervisor/mod.rs	Supervisor::start runs the recovery check in a blocking background task and ignores initialization failures.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Supervisor
  participant BootManager
  participant auto-launcher
  Supervisor->>BootManager: Initialize during startup
  BootManager->>auto-launcher: Read registered executable path
  auto-launcher-->>BootManager: Return registered path
  BootManager->>auto-launcher: Re-register when the path is stale
  BootManager-->>Supervisor: Finish without interrupting startup

Loading

Possibly related PRs

• jdx/pitchfork#616: Both changes use PITCHFORK_BIN to resolve the current executable path.

Suggested reviewers: jdx

Poem

I hop through startup, quick and bright,
Checking paths in morning light.
If the launcher wandered away,
I register it back today.
Boot keeps moving—hip hip hooray!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: automatic repair of stale boot registration during supervisor startup.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

The PR adds best-effort repair of stale boot registrations when the supervisor starts.

• Upgrades auto-launcher to expose the registered application path.
• Compares the registered path with the current binary and overwrites stale registration.
• Runs repair asynchronously so supervisor startup is not blocked.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported registration-loss path was removed by no longer disabling the existing registration before attempting replacement.

Important Files Changed

Filename	Overview
Cargo.toml	Updates auto-launcher to the release required for reading the registered application path.
Cargo.lock	Records the corresponding dependency resolution changes.
src/boot_manager.rs	Adds stale-path detection and directly overwrites stale registration without first deleting the existing entry.
src/supervisor/mod.rs	Starts boot-registration repair as a non-blocking background task during supervisor startup.

_{Reviews (2): Last reviewed commit: "fix(boot): overwrite stale registration ..." | Re-trigger Greptile}

[coderabbitai]

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/boot_manager.rs`:
- Around line 253-257: Update the repair path around self.current.enable() to
call BootManager::enable() via self.enable() directly, without first calling
disable(). Preserve the existing error handling and stale-registration behavior
while ensuring privilege-level validation and macOS legacy cleanup run during
repair.
- Around line 253-257: Update the registration write flow used by
BootManager::current.enable() to write the new contents to a temporary file and
atomically rename it over the existing registration, preserving the old file if
writing fails; alternatively extend the dependency contract with equivalent
backup-and-restore behavior. Ensure the fallback around this enable call still
retains the prior valid registration on any write error.

In `@src/supervisor/mod.rs`:
- Around line 385-387: Update the unsupported-platform BootManager
implementation in boot_manager.rs to define check_and_reregister_if_stale with
the same callable interface as the supported implementations, using a no-op body
so Supervisor::start() type-checks on all targets while BootManager::new()
continues returning its existing error.
- Around line 385-388: Update the BootManager initialization inside the
spawn_blocking closure to match on BootManager::new() instead of discarding Err
values; preserve the existing stale-registration check on success, and log the
initialization error on failure before continuing startup.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 7fccd405-a8e0-42ec-949f-50c1f3906d56

📥 Commits

Reviewing files that changed from the base of the PR and between 3a2b3e8 and 6b0cfe7.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

• Cargo.toml
• src/boot_manager.rs
• src/supervisor/mod.rs