Claude Code in launchd: My Nightly claude -p Job Worked 6 of 14 Nights

A developer documented running Claude Code headless via a macOS launchd agent for 14 nights, during which the nightly `claude -p` job produced a usable morning note on only 6 of those nights. The failures traced to launchd's minimal PATH (exit 127 because `claude` and its `node` shebang weren't found), the default working directory of `/` preventing CLAUDE.md from loading, and headless permission prompts being auto-denied while still exiting 0. The fixes were setting PATH and WorkingDirectory in the plist, adding StandardOutPath/StandardErrorPath logging, pre-approving tools with `--allowedTools`, and verifying the output file exists.

For two weeks I woke up and checked for a markdown file that should have been written at 3:00 AM. On 8 of 14 mornings it either wasn't there, was empty, or showed up after I'd already finished my coffee. The job was simple. A macOS launchd agent ran Claude Code headless with claude -p every night, read yesterday's commits across four repos, and wrote a one-page morning note. It worked perfectly every single time I ran it from my terminal. That is exactly the trap: running Claude Code in launchd is a different environment from your shell, and launchd doesn't tell you when something goes wrong. Here's the autopsy, night by night, plus the plist that finally worked. PATH=/usr/bin:/bin:/usr/sbin:/sbin .zshrc . claude isn't on that PATH, so you get exit 127. /usr/bin/env node , so node must be on PATH too. Set PATH in the plist's EnvironmentVariables . / . CLAUDE.md never loads. Set WorkingDirectory . claude -p can't answer permission prompts. --allowedTools and verify the output file exists. pmset to wake the machine, or accept late runs. One plist in ~/Library/LaunchAgents , one shell command, one target file. The first version looked like this: <key ProgramArguments</key <array <string /bin/zsh</string <string -c</string <string claude -p "$ cat ~/notes/nightly-prompt.md " ~/notes/morning.md</string </array <key StartCalendarInterval</key <dict <key Hour</key <integer 3</integer <key Minute</key <integer 0</integer </dict The prompt asked Claude to run git log --since=yesterday in four repos, group the commits by theme, flag anything that touched auth or billing code, and write the summary to ~/notes/morning.md . In my terminal: about 40 seconds, about $0.30 on API billing, a nice clean note. I loaded it with launchctl bootstrap gui/$ id -u ~/Library/LaunchAgents/com.me.nightly.plist and went to bed feeling clever. Because launchd jobs don't inherit your shell's PATH. A LaunchAgent starts with /usr/bin:/bin:/usr/sbin:/sbin , and zsh -c in non-interactive mode doesn't read .zshrc , which is where my npm global bin and Homebrew paths live. Nights 1 to 3: empty morning.md . The redirect created the file, claude was never found, and stderr went nowhere because I hadn't set StandardErrorPath . I only found the exit code by running launchctl print gui/$ id -u /com.me.nightly and reading last exit code = 127 . Three nights lost to a missing log path. Lesson one, before any other fix: always set these two keys. <key StandardOutPath</key <string /Users/me/logs/nightly.out.log</string <key StandardErrorPath</key <string /Users/me/logs/nightly.err.log</string Because the claude binary from npm is a Node script, and its first line is /usr/bin/env node . env searches PATH for node . Fix the path to claude and you just move the 127 one layer down. Night 4: I changed the command to the full path of claude . The error log now had a new message: env: node: No such file or directory Same exit code, different villain. The real fix is to set PATH for the whole job instead of patching individual binaries: <key EnvironmentVariables</key <dict <key PATH</key <string /opt/homebrew/bin:/Users/me/.npm-global/bin:/usr/bin:/bin:/usr/sbin:/sbin</string </dict Run which claude node git in your normal terminal and copy those directories. Don't guess. Because in print mode nobody is there to click "allow." When Claude asks to use a tool you haven't pre-approved, the request is denied, the model gets told no, and it does the polite thing: explains that it couldn't complete the task. The process still exits 0. Nights 5 and 6: exit code 0. morning.md contained a well-written paragraph saying it didn't have permission to run git log and suggesting I grant access. Technically a success. Practically a very articulate failure. There was a second bug hiding behind it. launchd's default working directory is / . So Claude started in the filesystem root, didn't load my project's CLAUDE.md which held the repo list and the formatting rules , and had to guess everything. Even with permissions fixed, night 6's partial output used the wrong repo names. The fix was two things: <key WorkingDirectory</key <string /Users/me/notes</string and an explicit tool allowlist on the command: claude -p "$ cat nightly-prompt.md " \ --allowedTools "Read,Write,Bash git log: " \ --output-format json /Users/me/logs/last-run.json Scope the Bash permission to the exact command prefix you need. A nightly unattended agent with blanket Bash access is a bad idea I don't need to test. I also stopped trusting exit codes. The wrapper script now checks that morning.md was modified in the last hour and is longer than 200 bytes. If not, it sends me a notification. That check alone would have saved me nights 1 through 6. if -z "$ find morning.md -mmin -60 -size +200c 2 /dev/null " ; then osascript -e 'display notification "nightly note missing" with title "claude -p"' fi Night 7: first real success. 3:00:04 start, 38 seconds runtime, $0.31 from total cost usd in the JSON output. It runs late, once. If the machine is asleep at the scheduled time, launchd starts the job the next time it wakes, and multiple missed intervals collapse into a single run. Plain cron on macOS is worse: a missed time is simply skipped. Nights 9 and 12: my laptop was closed and on battery. The note showed up at 7:52 and 8:15, the moment I opened the lid. It was correct. It was also useless, because the whole point was to have it before I sat down. Two options: sudo pmset repeat wakeorpoweron MTWRFSU 02:55:00 . On a laptop this is only reliable when it's plugged in. I did the first one and leave the laptop on the charger overnight. Nights 13 and 14 ran at 3:00. | Nights | Result | Cause | |---|---|---| | 1-3 | Empty file | claude not on launchd PATH, no stderr log | | 4 | Empty file | /usr/bin/env node couldn't find node | | 5-6 | Polite apology | Tool permission denied in -p mode, cwd was / | | 7, 8, 10, 11, 13, 14 | Worked on time | | | 9, 12 | Worked, 5 hours late | Laptop asleep, job fired on wake | Six of fourteen on time. Two late. Six broken. Total spend across all fourteen nights was about $2.40, because the broken runs mostly cost nothing: you can't get billed by a binary that never starts. The embarrassing part is that none of these were Claude Code bugs. Every failure was environment: PATH, shebang, working directory, permissions, power management. The model was fine. My assumption that "it works in my terminal" meant anything was the bug. <?xml version="1.0" encoding="UTF-8"? < DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" <plist version="1.0" <dict <key Label</key <string com.me.nightly</string <key ProgramArguments</key <array <string /bin/zsh</string <string /Users/me/notes/run-nightly.sh</string </array <key WorkingDirectory</key <string /Users/me/notes</string <key EnvironmentVariables</key <dict <key PATH</key <string /opt/homebrew/bin:/Users/me/.npm-global/bin:/usr/bin:/bin:/usr/sbin:/sbin</string </dict <key StartCalendarInterval</key <dict <key Hour</key <integer 3</integer <key Minute</key <integer 0</integer </dict <key StandardOutPath</key <string /Users/me/logs/nightly.out.log</string <key StandardErrorPath</key <string /Users/me/logs/nightly.err.log</string </dict </plist Test it without waiting for 3 AM: launchctl kickstart -k gui/$ id -u /com.me.nightly . Then read both log files. If you only do one thing from this post, do that before your first real night. Because launchd runs your Claude Code job in a stripped-down environment: a minimal PATH without your Node or npm directories, no shell profile, a working directory of / , and no human to approve tool permissions. Set PATH and WorkingDirectory in the plist, pass --allowedTools scoped to the exact commands the prompt needs, log stdout and stderr to files, verify the output file instead of the exit code, and schedule a pmset wake if the Mac might be asleep. Those five fixes are the difference between my 6-of-14 first two weeks and a job that now lands at 3:00 sharp. Written by the developer behind Preterview https://preterview.com/en , an interview prep platform.