Skip to content

launchd bootstrap failure falls back to unmanaged processes but reports 'running' #6

Description

@alecmarcus

Summary

When launchctl bootstrap fails, _install_launchd() falls back to _start_services_direct() and then reports worker running / MCP running. The processes are running, but they are unmanaged orphans — not registered with launchd, so they do not survive logout or reboot, and KeepAlive never applies.

The install summary panel prints "Flex is ready." with no indication that service installation failed.

What I saw

  [warn] launchctl bootstrap dev.getflex.worker.plist: Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.
  [warn] launchctl bootstrap dev.getflex.mcp.plist: Bootstrap failed: 5: Input/output error
  [warn] launchctl bootstrap dev.getflex.refresh.plist: Bootstrap failed: 5: Input/output error
  worker             running
  MCP                running

The warnings scroll past; the status lines say running; the panel says ready. Afterwards:

$ launchctl list | grep flex
(nothing)

$ pgrep -fl "flex.daemon|flex.mcp_server"
89235 ... -m flex.daemon --no-refresh --no-background
89236 ... -m flex.mcp_server --http --port 7134

Live processes, zero launchd registration. A reboot would have left a registered MCP endpoint in ~/.claude.json pointing at nothing.

On the bootstrap failure itself

I could not reproduce the 5: Input/output error. Running the identical command by hand from a normal shell immediately afterward succeeded:

$ launchctl bootstrap gui/$UID ~/Library/LaunchAgents/dev.getflex.worker.plist
$ echo $?
0

All three plists pass plutil -lint, nothing was disabled in print-disabled, and no conflicting label was registered. So the EIO may well be environmental or a race with the just-written plist rather than a flex defect.

The reporting is the part I would call a bug regardless of that cause: a fallback that produces non-persistent services should not be presented identically to a successful install.

Suggestion

Distinguish the two states in the status output — e.g. running (not installed — will not survive reboot) — and surface the bootstrap failure in the final panel rather than only as scrolled-past warnings. A flex health field for "services registered with the init system" would also make this detectable after the fact; it currently reports status: ok in this state.

Environment

getflex 0.52.0 · macOS (Darwin 25.5.0, arm64) · Python 3.14.3 · module claude-code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions