LaunchAgent without rebooting? — by kithrup on Apple Developer Forums

advancedforumLink only (©)

Accepted self-answer: a LaunchAgent loaded for one user would not run for a second user because its stdout/stderr log file in /tmp had been created with mode 0644 on the first run and was not writable by others. Pre-creating the file with chmod a+rw and reloading the agent fixed it. Pointing logs to a per-user location is a safer alternative.

Quick steps

touch and chmod a+rw the log file
launchctl bootstrap gui/<uid> <plist>

Paraphrased from the source. Menus can differ by version, so check the original for full details.

Read the full thread on developer.apple.com

Source: LaunchAgent without rebooting? by kithrup on Apple Developer Forums. Licence: Link only (©).

Source reviewed: 2026-11-02
Link checked: 2026-11-02
Tested hands-on: Not by Oddbyte.Me

launchdlaunchagenttroubleshootinglogging

More in Scheduling (Task Scheduler, launchd, cron)

Jack of all tasks: launchd, and how to run periodic tasks — by Howard Oakley (Eclectic Light Company)

intermediatepage

Older but useful explanation of launchd replacing cron on the Mac, the five folders where launch plists live, and the difference that agents can interact with the user session while daemons cannot. Suggests checking for legacy crontabs and mentions the Lingon X editor.

LaunchAgents and LaunchDaemons: Closing the vulnerability — by Howard Oakley (Eclectic Light Company)

intermediatepage

Security-focused look at the LaunchAgents and LaunchDaemons folders: where they are, which are SIP-protected under /System/Library and which are not, and why malware uses them to persist. Useful for knowing which launch folders to audit.

Run bash (.sh) via launchd using a plist in /Library/LaunchAgents — by VikingOSX and etresoft on Apple Community

intermediateforum

VikingOSX shows a working LaunchAgent for a shell script: plist in ~/Library/LaunchAgents with 644 permissions, Label, RunAtLoad, StartInterval and full paths only. The original poster got theirs working after moving the script out of ~/Documents, and etresoft points to privacy permissions instead, noting shell scripts silently fail without Full Disk Access.