Claude Code on a launchd schedule, the input arbitration problem every other guide skips

Technically yes. cron is a thin shim over launchd on modern macOS, and the binary still ships. The reason every guide nudges you toward launchd is that cron jobs run under a stripped environment that does not inherit your user's GUI session, so any Accessibility-API call from a job kicked off by cron returns errAXAPIDisabled. You would have to grant Accessibility to /usr/sbin/cron itself, which is brittle and a system binary the OS may replace on a point upgrade. A LaunchAgent in ~/Library/LaunchAgents loaded with `launchctl bootstrap gui/$UID` runs in the exact same context as if you had typed the command in Terminal, which is what you actually want.

claude -p "<prompt>" exits after one response, prints the answer to stdout, and accepts no follow-up. That is the non-interactive shape you want for a scheduled job. Your ProgramArguments should be /bin/zsh -lc "/usr/local/bin/claude -p '<prompt>'" so the login shell sets your PATH (otherwise claude often is not on launchd's default PATH) and so node version managers like nvm or fnm get a chance to expose the right node binary. Capture stdout to a file via StandardOutPath and stderr via StandardErrorPath; without those, output goes to /dev/null and you cannot debug a silent failure.

One command: `claude mcp add macos-use -- npx -y mcp-server-macos-use`. The npm postinstall hook (package.json line 17) runs `xcrun swift build -c release`, so the only host requirement is the Xcode Command Line Tools. After install, the scheduled run can call open_application_and_traverse, click_and_traverse, type_and_traverse, press_key_and_traverse, scroll_and_traverse, and refresh_traversal. The first call from the scheduled context will fire a system Accessibility prompt the first time it executes, which is a problem if you are asleep at 3am, so manually run `claude -p "open Calculator"` in your Terminal once before scheduling so the prompt is satisfied while you are at the keyboard.

macos-use installs a head-insert CGEventTap at InputGuard.swift:113 around every disruptive call. The tap separates programmatic events from hardware events by eventSourceStateID (programmatic events have a non-zero stateID, hardware events have stateID == 0, checked at InputGuard.swift:329-332) and drops everything coming from your hardware except plain Esc with no modifiers (keycode 53, lines 340-351), which is the one-key abort. The tap auto-disengages after a 30-second watchdog (InputGuard.swift:24) so the worst case is a 30-second freeze if the agent hangs mid-call. For scheduled jobs, this means: at 3am you are asleep, no hardware events, the tap is a no-op; at 9am you are at the keyboard, the tap blocks your typing for the duration of one tool call (typically 700ms), and you can hit Esc to kill the run.

TCC (Transparency, Consent, Control) keys permissions on the code-signing identity of the executable that calls a protected API. When launchd spawns /bin/zsh which spawns claude which spawns mcp-server-macos-use, the AX call originates from mcp-server-macos-use, but TCC walks up the responsible-process chain and attributes the request to the responsible parent that the user has approved. In practice on macOS 13+, that ends up being the claude binary (because claude is the long-lived process that owns the MCP child). Symptom of getting this wrong: the first AX call returns errAXAPIDisabled even though you remember granting Terminal access. Fix: grant Accessibility to the actual claude binary path (find it with `which claude`, drag that file into System Settings > Privacy & Security > Accessibility, toggle on).

No. A LaunchAgent only fires while the user session is active. If your Mac is asleep at the scheduled trigger time, the job runs the next time the user logs in (StartCalendarInterval coalesces missed firings into one). To actually wake the machine, schedule a power-management event with `pmset repeat wake MTWRF 8:55:00` (cron-style, system-level, requires sudo). Pair the pmset wake five minutes before the LaunchAgent trigger and the run is reliable. This is also why a LaunchDaemon is tempting and wrong: a LaunchDaemon will fire while the screen is locked or the user is logged out, but it has no GUI session and cannot drive AX, so all you get is a daemon that wakes the machine and then fails.

Three places to look. First, the StandardOutPath and StandardErrorPath you set in the plist; that is where Claude Code's response and any MCP tool errors land. Second, /tmp/macos-use/ contains a timestamped .txt file per AX traversal (one line per element, `[Role] "text" x:N y:N w:W h:H visible`) and a screenshot per disruptive call, written by the macos-use server regardless of the host process; this is the cheapest way to confirm the agent actually saw the UI you expected. Third, `launchctl print gui/$UID/<label>` reports the last exit status and how many times the job has been spawned, which is the easiest tell for whether your trigger is even firing.

Yes. `launchctl kickstart -k gui/$UID/com.you.claude-code.morning` fires the job immediately and (with -k) kills any in-flight instance first. This is the right loop while you are dialing in the prompt: edit the plist, `launchctl bootout gui/$UID/<label>` and `bootstrap` again to reload, then `kickstart -k`. Do not edit the plist while the job is bootstrapped; launchd reads the plist at bootstrap time and ignores changes until you reload.

Two real ones. First, anything that requires the user to actually look at a screen, like solving a CAPTCHA in a web app, is going to fail; the agent can navigate to it but not solve it. Second, apps that run in secure-input mode (system password fields, 1Password unlock, sudo prompts in Terminal) drop synthesized key events; the macos-use type_and_traverse uses CGEvent and will not type into those fields. The escalation primitive set_value (writes via kAXValueAttribute directly on the AX element) sometimes works on these but not always. Schedule the safe stuff first: read-only summaries, app navigation, drafting Notes/Mail/Slack messages, scrolling Calendar.

Open source at github.com/mediar-ai/mcp-server-macos-use, MIT licensed. Written in Swift, ~2400 lines across Sources/MCPServer/main.swift (2056 lines, the JSON-RPC handler plus six tools) and Sources/MCPServer/InputGuard.swift (355 lines, the CGEventTap input arbiter). Distributed via npm so the install is one command and the postinstall hook builds the Swift release binary against your local Xcode toolchain.