bug: setup --yes crashes on Linux because scheduled automation is macOS/launchd-only #31

Activity

1. Priyanshubhartistm

   added

   bugSomething isn't workingSomething isn't working

   on Jul 13, 2026
2. divitsheth

   marked bug: getting error launchctl bootout failed #30 as a duplicate of this issue on Jul 14, 2026
3. Hotragn commented on Aug 19, 2026

   

   Hotragn

   on Aug 19, 2026

   More actions

   I went looking for the root cause of this while testing the Python codebase on Windows, and it turns out to be one thing rather than a per-command problem. Sharing in case it helps scope a fix, since there are currently four open/closed PRs touching this and they each patch a different layer.

   There is no platform gate anywhere. sys.platform and os.name do not appear in src/ at all, and core/platform.py does not exist. app.py wires the scheduler unconditionally:

   from codealmanac.integrations.automation import LaunchdSchedulerAdapter

   and integrations/automation/__init__.py re-exports only that one adapter. So launchd is not selected on macOS — it is the only thing there is.

   Why Linux fails the way it does. launchd_target() builds the service target:

   def launchd_target() -> str:
       return f"gui/{os.getuid()}"

   os.getuid() exists on Linux, so the code proceeds and shells out to launchctl. That binary is missing, run_launchctl catches the OSError and converts it to returncode=1. That is why this surfaces as a confusing launchctl bootout failed (#30) rather than a clean "scheduled automation is not supported on this platform".

   setup --yes leaves state behind before it fails. LaunchdSchedulerAdapter.install writes before it boots:

   def install(self, job: ScheduledJob) -> ScheduledJobStatus:
       job.plist_path.parent.mkdir(parents=True, exist_ok=True)
       ...
       with job.plist_path.open("wb") as handle:
           plistlib.dump(launchd_plist(job), handle, sort_keys=False)
       self.bootout(job)      # <-- fails here

   and plist_path_for is unconditional:

   return home / "Library/LaunchAgents" / f"{definition.label}.plist"

   So a failed setup on Linux/Windows still creates ~/Library/LaunchAgents/com.codealmanac.*.plist. On my Windows box that is a literal C:\Users\<me>\Library\LaunchAgents\ directory. services/setup/service.py has no scheduler references at all, so nothing gates this earlier.

   Windows is strictly worse than Linux here. os.getuid does not exist, so:

   AttributeError: module 'os' has no attribute 'getuid'
   

   And this one cannot be caught by the existing handler: launchd_target() is evaluated in the argument expression at launchd.py:69/78/91, so it raises before run_launchctl is entered and its except OSError never sees it. cli/execution.py then re-raises, giving a raw traceback and exit 1. That is 5 of the failures in uv run pytest on Windows.

   One more POSIX assumption in the same file, which would bite immediately after the above is fixed — launch_path in services/automation/jobs.py:

   (env_path or os.environ.get("PATH", "")).split(":")

   On Windows os.pathsep is ;, so PATH.split(":") shreds every entry at its drive colon (['C', '\Users\...\Scripts;C', ...]).

   On the overlapping PRs — for whoever picks this up, these all address this issue at different layers, so they are not really alternatives to each other:

   • fix(setup): reject unsupported platforms before mutation #48 — guards in SetupService (rejects unsupported platforms before mutation)
   • fix: automation platform guard - setup and config set no longer crash on Linux #32 — guards in AutomationService.reconcile + config set
   • feat: Linux support — graceful automation skip on non-macOS (fixes #31) #51 — adds an unsupported.py scheduler adapter + a core/platform.py
   • feat(automation): add Linux systemd user-timer scheduler #29 (closed) — added a real systemd adapter alongside launchd

   #51 is the only one that introduces the missing seam, and it looks like the layer the others are working around. Happy to help verify any of them on Windows if that is useful — I have the box, and I gather from #24 that the team does not.