# 5 launchd Traps I Hit Running Claude Code Automation 24/7 on macOS

> Source: <https://dev.to/bokuwalily/5-launchd-traps-i-hit-running-claude-code-automation-247-on-macos-32bi>
> Published: 2026-07-11 11:00:05+00:00

In earlier posts I walked through [a mechanism that auto-generates skills](https://zenn.dev/bokuwalily/articles/self-growing-skills) and [context auditing](https://zenn.dev/bokuwalily/articles/context-slimming). The whole point of these is to **run them automatically at a fixed time every night** — that's where the value comes from. Right now my setup has **20** `launchd`

jobs running (skill generation, context audits, a morning briefing generator, Vault ingestion, and more).

The catch: setting up scheduled jobs on macOS is far trickier than you'd expect. This post covers the **5 traps I actually hit and fixed, along with verified workarounds**.

`cron`

is dead on modern macOS
You register a job with `crontab -e`

and it **never runs even once**. That's the first trap. On modern macOS (Sequoia and later) the cron daemon effectively doesn't run, and jobs are silently skipped. You don't even get an error.

Here's how to check whether it's alive.

```
log show --predicate 'process == "cron"' --last 7d
```

If this returns **zero entries**, cron isn't running. Just migrate to `launchd`

. A `launchd`

job looks like this plist.

```
<key>Label</key><string>com.you.skill-harvest</string>
<key>ProgramArguments</key>
<array>
  <string>/bin/bash</string>
  <string>/Users/you/.claude/scripts/skill-harvest.sh</string>
</array>
<key>StandardOutPath</key><string>/Users/you/.claude/logs/skill-harvest.log</string>
<key>StandardErrorPath</key><string>/Users/you/.claude/logs/skill-harvest.log</string>
```

Loading and running immediately looks like this.

```
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.you.skill-harvest.plist
launchctl kickstart gui/$(id -u)/com.you.skill-harvest   # force a run to confirm it works
```

Note:`launchctl list`

/`launchctl load`

are legacy APIs. The modern ones are`launchctl print`

/`bootstrap`

/`kickstart`

. Mixing old and new leads to confusion.

`*/5`

directly in `StartCalendarInterval`

Trying to write "every 5 minutes" the way you would in cron gets you stuck. `StartCalendarInterval`

specifies **specific times**, and periodic syntax like `*/5`

isn't supported.

`StartInterval`

(in seconds; `300`

for 5 minutes)`StartCalendarInterval`

entries in an A few smaller traps that also bite:

`Label`

must be in `com.you.name`

format. `ProgramArguments`

`StandardOutPath`

/ `StandardErrorPath`

as absolute paths, output vanishes into `/dev/null`

.`node: command not found`

— the minimal-PATH problem of GUI launches
This is where I got stuck the hardest. Claude Code hooks (`PostToolUse`

, etc.) kept failing every time with `/bin/sh: node: command not found`

— even though `node`

works fine in the terminal.

The cause: **the /bin/sh -c of a child process spawned by a GUI-launched app doesn't read the login shell's profile (.zshrc); it only has a minimal PATH (/usr/bin:/bin:/usr/sbin:/sbin)**. So

`node`

in nvm or Homebrew isn't visible. launchd jobs fail for the same reason.The fix is to add `env.PATH`

at the top level of `~/.claude/settings.json`

and have it inherited by child processes.

```
"env": {
  "PATH": "/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/you/.local/bin"
}
```

The key is to **always include /opt/homebrew/bin**. If you hardcode only nvm's version-specific path (

`.../node/v24.x/bin`

), it goes stale the moment you do a major Node upgrade and becomes `not found`

again. Keeping `/opt/homebrew/bin/node`

as a fallback means it won't break.Here's how to reproduce and verify.

```
# reproduce with the old minimal PATH (not found appears)
env -i HOME="$HOME" /bin/sh -c 'PATH="/usr/bin:/bin"; node --version'
# resolve with the new PATH (the version prints)
env -i HOME="$HOME" /bin/sh -c 'PATH="/opt/homebrew/bin:/usr/bin:/bin"; node --version'
```

`timeout`

You wrap a script in `timeout 60 some-command`

and get `timeout: command not found`

. **macOS doesn't ship the GNU coreutils timeout by default.** Many articles and rules are written assuming

`timeout`

exists, so copy-pasting them silently misfires.

```
brew install coreutils   # installs gtimeout
```

Making your script handle both improves portability.

```
TIMEOUT_CMD="timeout 60"
command -v gtimeout >/dev/null && TIMEOUT_CMD="gtimeout 60"
$TIMEOUT_CMD some-command
```

Incidentally, **the bash version problem has the same root**. The bash bundled with macOS is 3.2, which lacks 5.x features like `$EPOCHREALTIME`

(microsecond-precision time). If you're writing measurement scripts, set the shebang to `#!/opt/homebrew/bin/bash`

to explicitly use 5.x.

`exit 78 (EX_CONFIG)`

crash loop
The last one was the nastiest. I had a real case where a job with `KeepAlive`

**crash-looped infinitely**, restarting **about 15,000 times over 6 days**. No process ever came up, and no logs were left. Looking at `launchctl print gui/$(id -u)/<label>`

showed `last exit code = 78: EX_CONFIG`

, with `runs`

climbing every few seconds.

**78 is not the app's own exit — it's launchd's synthesized "couldn't initialize the service," i.e. a failure at the spawn stage.** The fact that the log wasn't growing at all (frozen mtime) confirms it. If running the script manually starts up normally, the program itself is healthy and it's dying only under launchd.

Diffing against a healthy job's plist, I found three causes that mattered.

`~/Documents`

, `~/Desktop`

, etc.) → change it to `~/.claude/logs/`

or `~/Library/Logs/`

(this was the most likely culprit)`#!/usr/bin/env bash`

resolves, under the plist's PATH, to an unsigned Homebrew bash`ProgramArguments`

to `["/bin/bash", "script.sh"]`

to explicitly use the Apple-signed interpreter`WorkingDirectory`

unspecified`/`

. If the app writes data with relative paths, it writes to an unintended location (like `/tmp`

, which is wiped on reboot) and loses the data**Order matters** in the repair procedure.

```
# 1. stop the loop
launchctl bootout gui/$(id -u)/<label>
# 2. kill the orphan process holding the port, "after confirming its owner"
lsof -nP -iTCP:<port> -sTCP:LISTEN
# 3. fix the plist and reload it
launchctl bootstrap gui/$(id -u) <plist>
# 4. verify
launchctl print gui/$(id -u)/<label> | grep -E 'state =|runs =|last exit'
```

Warning:`KeepAlive=true`

does not fix a spawn failure. Without a`ThrottleInterval`

(around 30 seconds), an infinite loop at intervals of a few seconds piles`runs`

up into the tens of thousands.

One last landmine. When inspecting a plist, if you get the arguments to `plutil -extract ... -o <file>`

wrong, you **overwrite and destroy the original plist with the output** (one of my job's plists actually became a 76-byte JSON fragment). When investigating with `plutil`

, always output to `-o -`

(stdout) or a separate file.

| Trap | Workaround |
|---|---|
| cron doesn't run | Check liveness with `log show` → migrate to launchd |
Can't write `*/5`
|
`StartInterval` (seconds) or expand into an array |
`node: command not found` |
Add `/opt/homebrew/bin` to `env.PATH` in `settings.json`
|
No `timeout`
|
`brew install coreutils` → `gtimeout` fallback |
`exit 78` loop |
Log path outside TCC / explicit `/bin/bash` / `WorkingDirectory` / `ThrottleInterval`
|

Automation isn't "set it and forget it" — it's **only complete once liveness checking is part of it**. If you build the habit of periodically checking with `launchctl print`

whether the log's mtime is advancing as expected, you'll notice jobs that have silently died much sooner.

Across these three posts, I've built an environment where skills grow, context stays light, and automation runs around the clock. Next, I plan to write about the mechanism that **rolls all of this up into a morning briefing**.

*Written by **Lily** — I ship iOS apps and automate my content stack with Claude Code.

Follow along: [Portfolio](https://bokuwalily.com) · [X](https://x.com/bokuwalily) · [GitHub](https://github.com/bokuwalily)*