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
Summary
When
launchctl bootstrapfails,_install_launchd()falls back to_start_services_direct()and then reportsworker running/MCP running. The processes are running, but they are unmanaged orphans — not registered with launchd, so they do not survive logout or reboot, andKeepAlivenever applies.The install summary panel prints "Flex is ready." with no indication that service installation failed.
What I saw
The warnings scroll past; the status lines say
running; the panel says ready. Afterwards:Live processes, zero launchd registration. A reboot would have left a registered MCP endpoint in
~/.claude.jsonpointing 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:All three plists pass
plutil -lint, nothing was disabled inprint-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. Aflex healthfield for "services registered with the init system" would also make this detectable after the fact; it currently reportsstatus: okin this state.Environment
getflex 0.52.0 · macOS (Darwin 25.5.0, arm64) · Python 3.14.3 · module
claude-code