Running Claude Code on a remote Mac: connect, log in, keep long jobs alive

Claude Code needs Node.js 18 or newer. Machines are delivered with Node and Claude Code already installed, so you can usually skip to the login. If not:

If npm throws a permissions error, check which Node you have: global installs under /usr/local need root, Homebrew's /opt/homebrew does not. Reaching for sudo npm usually creates a worse problem than it solves.

node -v                              # confirm >= 18
npm i -g @anthropic-ai/claude-code   # install
claude --version                     # verify

There are two common ways to authenticate: run claude and follow the browser authorisation (copy the link into your own browser, sign in, paste the code back into the terminal), or set ANTHROPIC_API_KEY if you already have a key. Either way you sign in with your own account; the login step is yours to complete. Login state lives in your home directory, so reconnects and restarts usually keep it; a different system user does not share it and must authenticate again.

A dropped SSH session kills foreground processes, which is the usual reason a run “disappears halfway”. Put the work in tmux and a disconnect only takes down your connection, not the job.

To tell whether a job is actually running, check two things: tmux ls still lists the session, and the output file you redirected to is still growing. A closed screen-sharing window is not a dead job — look at the session before restarting anything.

tmux new -s cc          # new session; run claude inside it
# after reconnecting:
tmux attach -t cc       # back to the same screen

The other trap is sleep. macOS tries to sleep when idle and suspends long jobs. Block it with caffeinate: run caffeinate -dimsu in the background, or wrap the job as caffeinate -i tmux new -d -s cc 'claude'. Put that in a LaunchAgent so it comes back after a reboot; an active screen-sharing session also inhibits sleep, but do not rely on it.

For work that must run at a fixed time (daily reports, syncs, batch passes), launchd is more reliable than cron on macOS because it does not silently skip a run missed during sleep.

The difference is reliability, not syntax: cron drops a scheduled point it slept through, launchd catches up after wake. For anything that must happen once a day, use launchd. Save this plist as ~/Library/LaunchAgents/com.easycc.job.plist:

<?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.easycc.job</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/zsh</string><string>-lc</string>
    <string>cd ~/work && claude -p "..." >> ~/logs/job.log 2>&1</string>
  </array>
  <key>StartCalendarInterval</key><dict>
    <key>Hour</key><integer>3</integer><key>Minute</key><integer>0</integer>
  </dict>
  <key>RunAtLoad</key><false/>
</dict></plist>

Load it with launchctl load -w ~/Library/LaunchAgents/com.easycc.job.plist. For simple cases crontab -e still works, but cron's PATH is minimal: write full paths for node and npm, and source ~/.zshrc or export PATH at the top of the script.

These three cost a new user half an hour each. Knowing them in advance costs nothing.

• Different PATH: a non-interactive SSH login does not read ~/.zshrc, and npm globals live under /opt/homebrew/bin, so cron cannot find the command. Use absolute paths, or source the profile explicitly.
• EACCES on a global npm install: system Node needs elevated permissions for global packages. Homebrew or nvm installs usually do not. If you already hit it, change npm's prefix rather than reaching for sudo npm.
• The process vanishes after a disconnect: the machine did not crash, the foreground process ended with the SSH session. Use tmux or nohup; never run a long job in a bare ssh session.

Watch the timezone too: the machine runs UTC+5, so “3 a.m.” is a different moment than you think. launchd's StartCalendarInterval follows the machine's local time — print date once in the script to confirm.

After the first successful session, pin a few things down: keep projects under ~/work with one long-lived tmux session, put anything that must survive a reboot into a LaunchAgent, and send logs to ~/logs split by day. Then a reboot, a flaky network or a different laptop changes nothing about the work already running.

One thing people forget is disk headroom. Claude Code session transcripts, build artefacts and Xcode's DerivedData all grow; a 256 GB machine gets tight within a month or two of heavy use. Clearing ~/Library/Developer/Xcode/DerivedData and old build directories periodically is far cheaper than upgrading later.