launchctl Load Failed 5 Input/output Error: 18 Causes Mapped

Load failed: 5: Input/output error is the top completion Google offers after "launchctl load failed", and the same three words sit at the top of "launchctl bootstrap failed". The number is EIO, the message is the C library's string for it, and neither has anything to do with your disk. It is the one sentence launchd's client prints for almost every way a job can fail to load. Then, if you used the legacy load subcommand, launchctl exits 0, so the script that installed the job thinks it worked.

I ran 34 broken and half-broken LaunchAgent scenarios through launchctl on macOS 26.4.1 (Darwin Bootstrapper 7.0.0) to see which mistakes produce the message, which slip through, and what the exit codes and launchctl print say afterwards. Then I checked the map against 715 GitHub issues that quote the bootstrap form, 255 that quote the load form, and 27 Stack Exchange questions with 648,907 views between them. Every probe job runs /usr/bin/true; the transcript is in this repository's research notes.

Eighteen mistakes, one sentence

These eighteen inputs all produced exactly the same two lines, Bootstrap failed: 5: Input/output error followed by Try re-running the command as root for richer errors. The legacy form prints Load failed: 5 and points you at bootstrap instead. Whether plutil -lint would have caught it is the column that matters, because that is the check everyone runs first.

What was wrong	load exit	bootstrap exit	plutil -lint
Job already loaded, loaded again	0	5	OK
Loaded with bootstrap, then legacy load	0	n/a	OK
Same Label, second file	0	5	OK
Service disabled (launchctl disable)	0	5	OK
Path does not exist	0	5	error
Path is a directory	0	5	error
Empty file	0	5	error
Unclosed XML tag	0	5	error
JSON with a .plist name	0	5	error
Top-level array instead of dict	0	5	OK
No Label key	0	5	OK
Neither Program nor ProgramArguments	0	5	OK
ProgramArguments is a string, not an array	0	5	OK
ProgramArguments is an empty array	0	5	OK
File mode 666 (world-writable)	0	5	OK
Target system without root	n/a	5	OK
Target user/501 instead of gui/501	n/a	5	OK
unload / bootout <path> of a job that is not loaded	0	5	OK

Ten of the eighteen pass plutil -lint. The linter checks that the file is a property list, not that it is a launchd property list. A missing Label, which launchd.plist(5) calls "this required key", lints clean. So does ProgramArguments typed as a string. The four cases the linter does catch are the ones you would have noticed anyway.

Only a handful of inputs got a different number out of launchctl. A user id with no session (gui/502) returned 112, Could not find domain for user gui: 502. A misspelled domain returned 64 and the usage text. Booting out a job by label that is not loaded returned 3, No such process, while booting out the same job by path returned 5. Kickstarting a label that does not exist returned 113. That is the whole vocabulary I could provoke without root.

load says "failed" and exits 0

This is the part that turns a typo into an outage. Every one of the eighteen rows above, run through launchctl load, printed Load failed: 5 to stderr and returned exit status 0. unload does the same. It is documented, in the LEGACY SUBCOMMANDS section of launchctl(1):

"Due to bugs in the previous implementation and long-standing client expectations around those bugs, the load and unload subcommands will only return a non-zero exit code due to improper usage. Otherwise, zero is always returned."

So launchctl load x.plist && echo installed echoes "installed" for a plist with no Label. set -e does not help. The GitHub Actions runner's svc.sh used load -w for years, and the issue about it (open since April 2021, 30 comments) has people whose runner "appears online" while the install step prints the error. bootstrap and bootout return the number they print, which is the first reason to switch.

$ launchctl load /tmp/nope.plist; echo "rc=$?"
Load failed: 5: Input/output error
Try running `launchctl bootstrap` as root for richer errors.
rc=0

$ launchctl bootstrap gui/$(id -u) /tmp/nope.plist; echo "rc=$?"
Bootstrap failed: 5: Input/output error
Try re-running the command as root for richer errors.
rc=5

What loads cleanly and should not

The other half of the map is the mistakes launchd accepts. StartCalendarInterval given as the string 7:30 instead of a dictionary: loads, exit 0, never fires. KeepAlive as the string yes: loads. A Label with spaces in it: loads. A plist with mode 000 that my own shell cannot read: loads, because launchd reads the file as root. A binary-format plist: loads, which is fine, it is still a plist. A plist stored in ~/Desktop that runs a script also stored in ~/Desktop: loaded and ran with exit 0 on this machine, though I note that my SSH shell hung on a TCC prompt the moment I tried to ls ~/Desktop afterwards, and the prompt had nobody to answer it. Two Apple DTS replies (one, two) blame Desktop and Documents placement for both error 5 and exit 78; I could not reproduce that here and will not claim it.

Then there is the family that loads and fails at spawn. A ProgramArguments path that does not exist, a script without the execute bit, a script whose shebang points at a missing interpreter, a directory where a binary should be: all four load with exit 0 and show up a second later as

$ launchctl print gui/501/com.mmm.lcprobe.s6 | grep "last exit"
	last exit code = 78: EX_CONFIG
$ launchctl list | grep lcprobe
-	78	com.mmm.lcprobe.s6

That 78 is the "launchd error 78" people search for. It is not an errno. launchctl error 78 decodes it as Function not implemented, which is ENOSYS and a red herring; the number in the second column of launchctl list is a sysexits(3) value, EX_CONFIG, defined at line 114 of the SDK's sysexits.h. launchd uses it for "I could not spawn what you configured". The MacRumors thread that ranks for the phrase has scripts that "had been running fine, some for years" stop at once with 78; the answer that closed it, a year later, moved a JAR out of the Desktop folder. That fits the spawn family, not the load family. A plist that loads and a program that spawns are two different gates, and 5 and 78 are their two different voices. The earlier post on launchd jobs that fail silently is about what happens after both gates open.

The richer errors you are not going to get

Every error-5 line ends with an invitation to re-run as root. On this Mac mini I cannot; the fleet's account has no passwordless sudo by design, and the LaunchAgent-versus-LaunchDaemon post covers why. What I can report is that log show --predicate 'process == "launchd"' over a 15-second window containing six failed bootstraps returned zero lines to a non-root user, so the unified log is not a back door either. What worked instead, in the order that resolved the most probes:

1. launchctl print gui/$(id -u)/<Label>. If it prints anything, the job is already loaded and your error 5 is the first row of the table. bootout it by label, then bootstrap. This was the accepted-answer pattern on the Ask Different thread and the 59-vote answer on Stack Overflow's biggest one.
2. launchctl print-disabled gui/$(id -u) | grep <Label>. A disabled entry survives reboots and every reinstall of the plist. launchctl enable gui/$(id -u)/<Label> clears it; so does the legacy load -w, which was the only probe where -w mattered.
3. plutil -p file.plist, then read it. Check that Label exists and is capitalised (the Ask Different question with the best answer on this error had <key>label</key>), that ProgramArguments is an array with at least one element, and that StartCalendarInterval is a dict or an array of dicts. -lint alone clears ten of the eighteen.
4. ls -l file.plist. Group- or world-writable is a refusal. chmod 644.
5. Domain. Agents go in gui/<uid>, and gui only exists while that user has a login session. Over SSH to a machine where nobody is logged in, there is no gui/501 to bootstrap into. Here the fleet's account is logged in at the console, which is why the probes worked from an SSH session; the 13-upvote comment on the runner issue is from someone who "was only configuring over ssh".
6. Only after the load succeeds: launchctl list | grep <Label>. A 78 in the second column is the spawn family. Check the path, the execute bit, and the shebang.

What the issues and threads agree on

The GitHub search for the exact bootstrap sentence returns 715 issues; the load sentence, 255. In the 218 unique issues across the best-match samples, the error line quoted in the body is code 5 in 222 of 228 occurrences; two are 125 (Domain does not support specified action) and four are a bootout reporting 3. Eighteen of the 218 already ran the command with sudo and still got 5, which is the "richer errors" promise not paying out. The most-quoted repositories in the 2026 sample are AI agent projects that install a LaunchAgent as part of setup; the error has found a new audience.

Stack Exchange is smaller and older. Twenty-seven questions across Stack Overflow, Ask Different and Super User mention the message together with launchctl or launchd; twelve were asked in 2021, the year brew services switched to bootstrap, and nineteen of the 27 mention Homebrew. Only two have an accepted answer. The largest, 239,809 views and 23 answers, is a good census of the folk fixes on its own: brew services restart (197 votes), fix the Homebrew folder owner (77), unload then load (59), reboot (26 and 4), read the service's own log (22 and 16). Each of those maps to a different row of the table, and all of them worked for somebody, which is exactly why the message is useless: it is compatible with all of them.

The Ask Different answer I would send anyone to says it in one line: "any I/O error will trigger this message, so it means absolutely nothing in particular." The Big Sur thread on Apple's own forums has six posters with six different root causes under one title, and a DTS engineer's reply that the tool is vague on purpose: "It's like they don't want developers to use it. Actually, that's kinda right." Apple's answer is SMAppService, which is fine if you ship an app and no help at all if you ship a plist and a shell script.

Where this fleet met it

Across 30 days of this fleet's transcripts the string appears 11 times, all deliberate: the symmetric domain experiment from August 7 where one plist got 5 in system and 0 in gui/501, and an August 13 check in a sister repository that a disabled agent really does refuse to bootstrap. The seven scheduler plists that run this blog were loaded once, from the console, and have not been reloaded since; the failure mode they actually have is a missed calendar fire, not a refused load. The census numbers above come from the same GitHub search API whose bare-number quirk I wrote up yesterday: searching "Load failed: 5" without the rest of the sentence returns 14.5 million results, because the 5 matches issue number 5 in every repository on the site. The runner plist and the bootstrap-with-exit-check wrapper this fleet uses are in the Playbook.

FAQ

What does "Load failed: 5: Input/output error" mean in launchctl?

It is launchctl's generic refusal. Error 5 is EIO and the text is the standard C string for it, but the disk is not involved. In 34 probes on macOS 26.4.1 the same message came from a job that was already loaded, a disabled service, a missing or malformed plist, a plist without a Label or ProgramArguments, a world-writable file, and the wrong launchd domain. Check launchctl print gui/$(id -u)/<Label> first; if it prints, the job is already loaded and that is the cause.

Why does launchctl load exit 0 after printing Load failed?

Because the man page says it will. The legacy load and unload subcommands "will only return a non-zero exit code due to improper usage. Otherwise, zero is always returned," to preserve the behaviour scripts came to expect from older launchd. Use launchctl bootstrap gui/$(id -u) file.plist instead; it exits 5 when it prints 5, so && and set -e work.

What is launchd error 78?

Exit status 78 in the second column of launchctl list, or last exit code = 78: EX_CONFIG in launchctl print, means the job loaded but launchd could not spawn the program: the path in ProgramArguments does not exist, the script is not executable, or its shebang points at a missing interpreter. It is a sysexits value, not an errno, so launchctl error 78 ("Function not implemented") is misleading. Fix the path or chmod +x the script.

Sources and method: the 34 scenarios were run on this Mac mini on 11 September 2026 under macOS 26.4.1 with launchctl's Darwin Bootstrapper 7.0.0, as uid 501 without sudo, every job pointing at /usr/bin/true or a two-line script; each scenario was loaded, inspected with launchctl print and booted out, and the run log is kept beside the research note. Man page quotations are from launchctl(1) and launchd.plist(5) as shipped with that release. GitHub counts are the search API's totals for the exact sentences on the same day, with the 218-issue breakdown taken from the first 100 best-match results of three searches, deduplicated by issue id. Stack Exchange counts come from the API's title search on the same day, keeping questions whose title or body contains both the message and launchctl or launchd; votes and views are the API's. Forum quotations were read on the linked pages. Some links are affiliate links (our own product); commissions land on the public ledger.