What breaks when Claude Code runs overnight with nobody watching

A developer's survey of unattended coding-agent runs found that most overnight failures stem from plumbing rather than bad model output: schedulers that silently skip or misfire, permission prompts that stall runs until morning, and destructive commands that slip past permission checks. One documented case saw Claude Code in auto mode run a test before writing a home-directory guard, deleting roughly nine days of unpushed commits along with the local .git directory. The recommended defenses are sandboxing (sandbox.enabled: true with allowUnsandboxedCommands: false), off-machine backups, frequent pushes, and verifying output files rather than trusting exit codes.

Scheduling a coding agent takes a few minutes. A launchd plist, a cron line or a desktop scheduled task will start Claude Code or Codex at 2am. Getting something useful out of it by 8am is harder. I've been reading what people who run agents on a timer have posted lately: a dev.to write-up of a week running as a scheduled agent https://dev.to/johnclaude1337/running-an-ai-agent-on-a-daily-schedule-what-works-and-what-quietly-breaks-3moo , the HN thread on tmux and Claude Code https://news.ycombinator.com/item?id=50148855 , an r/LLMDevs thread asking what you actually record when an agent runs unattended https://www.reddit.com/r/LLMDevs/comments/1x5ksgn/what do you actually record when an agent runs/ , and a handful of newer posts. The same failures come up again and again, and very few of them are the model writing bad code. Most are plumbing. Here they are, grouped by what you find in the morning. The thing that was supposed to start the run wasn't running. What helps: start runs from launchd systemd on Linux , not from an app window. launchd has one more advantage over cron on a laptop. If the machine is asleep at the scheduled time, cron skips the job, while launchd runs it when the machine wakes. Keep the Mac awake for the window you need caffeinate -i covers idle sleep, not a closed lid on battery , and run the session somewhere you can reattach to. From the scheduler's side this one looks fine. A post from this week https://dev.to/eye java 420f1faa10ae8b86/my-unattended-job-ran-on-time-and-did-nothingmy-unattended-job-ran-on-time-and-did-nothing-aef has a clean example. A launchd job fired at 21:00 two nights in a row and exited one second later. The runbook was handed to the agent CLI as an argument, it started with YAML frontmatter, and the CLI parsed --- as an unknown option and quit with exit code 1. The fix was putting -- before the prompt so everything after it is read as text. The exit status had been sitting in launchctl list since the first night, and nobody checked it. Two more versions of the same thing: What helps: check the output itself. Does the file exist, is it from tonight, does it have anything in it. The exit code and the agent's last message can both look fine when it doesn't. A permission prompt at 2am means the run does nothing until you wake up. Same for any step that needs a human yes, like publishing something public. The scheduled-agent post adds browser sign-ins: one lasted about a day, the next run hit a login page, and an agent shouldn't be typing passwords. What helps: This post https://dev.to/ryodevapp/my-macs-files-were-deleted-while-claude-code-was-building-a-guard-against-deleting-files-df9 is worth reading before your first overnight run. The author had Claude Code working on an iOS app overnight in auto mode, where a classifier answers the permission prompts. A subagent asked to add a home-directory guard to a script that runs rm -rf ran the test before writing the guard, the test was given the real home directory, and about 9 days of unpushed commits went with the local .git . Their explanation: the permission checks and their own hooks look at the one command line Claude types, and they can't see a path passed to rm -rf inside a script that command runs. Their main defenses now are the sandbox sandbox.enabled: true and allowUnsandboxedCommands: false in settings , a backup off the Mac, and pushing commits soon after approving them. Smaller collisions show up too. In the issue loop, a batch of refactor PRs collided on CLAUDE.md and README.md , so each issue now gets its own git worktree and can be held behind another one with an After N line. And an Ask HN from this week https://news.ycombinator.com/item?id=50181801 makes the point that the risk grows when a scheduled agent has MCP servers and credentials on the machine. On a subscription, a bad night costs you the next day. In the agent-usage-guard Show HN https://news.ycombinator.com/item?id=50198936 , a commenter who had burned a whole usage window in minutes more than once wrote a hook that stops subagents from spawning past 80% of the window. They report their biggest burst went from 365 spawned agents to 27. The issue loop reads the same numbers /usage shows before every issue and ends the night when tonight has used 10 points of the week, the week is past 70%, or the 5-hour window is past 80%. If it can't read the numbers it assumes 100% and stops. The one weekend its author raised the night allowance to 60 points, the week went from 20% to 48%. A run that went fine but left nothing to read still costs you a morning, because you end up opening every session to find out what happened. In the tmux thread one commenter called the sessions "an implementation detail" they only want to jump into "when something is wrong". Another built their own setup mainly to see which sessions are still running, which need help and which are done. The cheapest fix is a few lines at the end of every brief: When you finish, write a short report to reports/<date .md: what you changed, which files, anything you assumed, and what you need from me. In the morning you read the reports and only open a transcript when a report says something went wrong. The scheduled-agent post also describes a loop to watch for: when nothing outside changes, each fresh session reads the plan, finds nothing new and writes the same plan for tomorrow. A decision date written into the plan "if X still isn't live by day 7, do Y" ends it. I wanted to run agents locally off-hours on the Claude subscription I already pay for, so I built a Mac app for it, Overboard https://tryoverboard.com/?utm source=devto&utm medium=article . Each scheduled brief any prompt or plugin slash command: a security review, a blog post, social discovery runs as a real Claude Code session in its project folder that you can watch or take over. There's a keep-awake menu so the Mac doesn't sleep while agents need it, and each department has a captain that reviews the last runs and only asks me when it's stuck. Sessions run in auto mode, so section 4 applies to it as much as anything else: the sandbox, the deny list and the backup are still yours to set up. The Mac has to be awake and logged in.