bootstrap: honor macOS .service records that carry the full plist path - #164
Merged
Conversation
On macOS, the runner's svc.sh writes the absolute plist path into .service; on Linux it writes the bare service name. configure_service! assumed the Linux shape and joined the record under launch_agents_dir with a second .plist suffix, so on macOS PlistBuddy targeted a nonexistent doubled path and the real plist never received Umask 002 or AI_FLOW_AGENT_USER — caught live during the plans#36 ceremony. Use the record verbatim when it already names a plist; keep the join for the bare-name shape. Co-authored-by: Cursor <cursoragent@cursor.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
Caught live during the plans#36 ceremony: `dev runner register --org --ai-flow` reported writing the service env into
```
/Users/jpduchesne/Library/LaunchAgents/Users/jpduchesne/Library/LaunchAgents/actions.runner.d3mlabs.JeanPhiippesMBP.plist.plist
```
On macOS the runner's `svc.sh` writes the absolute plist path into `.service` (on Linux it is the bare service name). `configure_service!` assumed the Linux shape, joining the record under `launch_agents_dir` and appending a second `.plist`. Every PlistBuddy call hit a nonexistent path, so the real plist never received `Umask 002` or `AI_FLOW_AGENT_USER` — the runner restarted without the cooperative-access settings.
Fix: use the `.service` record verbatim when it already names a plist; keep the join for the bare-name shape. Test-first: new test writes a macOS-shaped record (absolute plist path) and asserts PlistBuddy targets it exactly — failed before the fix, passes after.
Note: 4 `BuildContainerTest` failures appear locally on any bootstrapped agent host (they hard-code `~/.dev/...` while DataRoot now resolves the shared root) — pre-existing on main, unrelated, issue to follow.
Made with Cursor