How to Schedule AI Coding Agents to Run While You Sleep

Every developer has had the same thought: what if my AI coding agent could keep working after I close my laptop? You have a backlog of refactoring tasks, a test suite that needs fixing across 40 files, or a migration from one API version to another. Each task takes Claude Code 5-15 minutes. Doing them one at a time, babysitting each run, means an entire afternoon lost to waiting.
The idea of scheduling AI coding agents to run autonomously -- queuing up work before bed and waking up to pull requests -- is not science fiction. It is the most practical productivity unlock available to developers using Claude Code today. But there is a gap between the dream and the reality of raw CLI usage that most people discover the hard way.
This guide covers exactly how to schedule Claude Code agents to run while you sleep using SuperBuilder, the free and open-source desktop app for Claude Code. We will walk through the task queue system, the reliability engineering that makes overnight runs viable, and a step-by-step workflow for queuing five tasks and waking up to results.
Table of Contents
- The Overnight Coding Dream
- Why the Raw CLI Cannot Do This
- How SuperBuilder's Task Queue Works
- Step-by-Step: Queue 5 Tasks Before Bed
- Use Cases for Overnight Agent Runs
- The Reliability Engineering Behind It
- Notifications and Monitoring
- Tips for Better Overnight Results
- FAQ
The Overnight Coding Dream
The math is straightforward. A single Claude Code session can handle substantial work: implementing a feature, fixing a class of bugs, writing tests for a module, or migrating a file from one pattern to another. Each of these tasks might take 5 to 20 minutes of agent time. If you have ten such tasks, that is one to three hours of compute time -- time where you are doing nothing but watching a terminal.
Now imagine queuing those ten tasks at 11 PM. You go to sleep. The agent works through them sequentially: task one finishes, task two starts, and so on. By 7 AM, you have ten completed tasks waiting for your review. That is an entire sprint's worth of mechanical work done while you were unconscious.
This is not a theoretical workflow. Developers using background AI agents and task automation are already reporting 2-3x throughput increases on codebases where the work can be decomposed into independent tasks. The constraint has never been the AI model's capability -- it is the tooling around it.
Why the Raw CLI Cannot Do This
Claude Code's CLI is powerful. Running claude -p "fix the auth bug" in a terminal gets you remarkably far. But for overnight, unattended operation, the raw CLI has fundamental limitations that break the workflow:
Terminal session fragility
Close your laptop lid, and your terminal session may die. SSH connections time out. macOS aggressively suspends background processes. Even with tmux or screen, you are fighting the operating system's power management rather than working with it.
No task queue
The CLI processes one prompt at a time. There is no built-in mechanism to say "run these five prompts sequentially." You could write a bash script with a loop, but that script has no error handling, no retry logic, and no awareness of whether the previous task succeeded or failed.
Rate limit crashes
Anthropic's API has rate limits. When Claude Code hits a rate limit during a long task, the CLI exits with an error. Your bash script sees a non-zero exit code and either stops entirely or blindly starts the next task without the context of what happened. There is no backoff, no retry, no recovery.
No zombie detection
Sometimes a Claude Code process hangs. The PTY produces unparseable output -- ANSI escape codes instead of JSON, a stream that stalls mid-response. In a terminal, you notice and hit Ctrl+C. In an unattended script, that process sits there forever, blocking everything behind it.
No notification system
Even if everything works perfectly, you have no way to know it finished. You wake up, open your laptop, and manually check each task. Did it complete? Did it error? Did it produce the right output? The feedback loop is entirely manual.
These are not edge cases. They are the normal failure modes of running any long-lived process unattended. Solving them requires purpose-built infrastructure.
How SuperBuilder's Task Queue Works
SuperBuilder is a free, open-source desktop app that wraps Claude Code with the infrastructure needed for reliable, unattended operation. Its task queue is the core feature that makes scheduling agents practical.

Sequential execution with isolation
Each task runs in its own Claude Code session, spawned as a PTY (pseudo-terminal) process via node-pty. Tasks execute sequentially -- one finishes before the next begins. This prevents resource contention and ensures each task gets Claude's full attention.
The queue is persistent. It survives app restarts, rate limit interruptions, and system sleep cycles. When SuperBuilder wakes up, it picks up where it left off.
Rate limit handling and auto-retry
When Claude Code hits a rate limit, SuperBuilder detects the failure and automatically retries with exponential backoff. Instead of crashing and losing progress, the queue pauses, waits for the rate limit window to reset, and resumes. This is critical for overnight runs where you might hit usage tier limits during extended sessions.
Atomic state management
Every queue operation uses atomic database updates. A task is not marked as "sent" until the PTY process confirms it has started. This prevents the classic race condition where a task appears complete in the UI but never actually ran.
Session context preservation
Each task can inherit context from previous runs or start fresh, depending on your configuration. For related tasks (like fixing bugs across a module), context preservation means the agent remembers what it already tried. For independent tasks, fresh sessions prevent context pollution.
Step-by-Step: Queue 5 Tasks Before Bed
Here is a practical walkthrough. We will queue five tasks for an overnight run on a TypeScript project.
Step 1: Open your project in SuperBuilder
Launch SuperBuilder and open your project directory. The app indexes your codebase and sets up the Claude Code integration automatically.

Step 2: Write your first task
In the prompt composer, type your first task. Be specific -- the more context you give, the better the overnight results:
Instead of sending it immediately, add it to the queue. SuperBuilder's queue system lets you stack multiple tasks that will execute in order.
Step 3: Add the remaining tasks
Queue up the rest of your overnight work:
Task 2 -- Test coverage:
Task 3 -- API migration:
Task 4 -- Documentation:
Task 5 -- Lint cleanup:
Step 4: Review the queue
Before walking away, review the queue order. SuperBuilder shows you all pending tasks with their prompts, estimated complexity, and execution order. You can drag to reorder, edit prompts, or remove tasks.

Put the most critical tasks first. If something goes wrong at 3 AM, you want the high-priority work to already be done.
Step 5: Configure notifications and start the queue
Enable desktop notifications so you get a summary when the queue completes. SuperBuilder's notification system includes dock badge updates and per-task status alerts.
Start the queue. SuperBuilder begins processing task one immediately. You can watch the first task start to verify everything is working, then close your laptop with confidence.

Step 6: Wake up to results
In the morning, open SuperBuilder. You will see a summary of all completed tasks: which succeeded, which hit errors, and what changes were made. Each task's full conversation history is preserved in the thread view, so you can review exactly what the agent did, step by step.
Review the changes, run your test suite, and push to your feature branches.
Use Cases for Overnight Agent Runs
Scheduling Claude Code agents is not just about convenience -- certain categories of work are dramatically better suited to background execution.
Overnight refactoring
Large-scale refactoring is the ideal use case. Rename a module, extract a class, migrate from callbacks to async/await, or restructure your project directories. These tasks are well-defined, mechanical, and time-consuming. The agent does not need your input mid-task, and the results are easy to verify with tests.
Queue up refactoring tasks organized by dependency order: extract the base classes first, then refactor the implementations, then update the consumers.
Test suite fixes
A failing CI pipeline with 30 broken tests is painful to fix manually but straightforward for an agent. Queue one task per test file or per failure category. The agent can read the error output, understand the expected behavior, fix the test, and verify it passes.
For large test suites, this can save an entire day of tedious debugging.
Documentation generation
Writing JSDoc comments, README files, API documentation, and code examples is important but rarely urgent. Queue documentation tasks for overnight runs and wake up to a fully documented codebase. The agent can follow your existing documentation style and cover every exported function.
Codebase migration
Migrating from one library version to another (React 18 to 19, Express 4 to 5, Stripe v2 to v3) involves updating hundreds of call sites. Each file's migration is independent and verifiable. Queue the migration file-by-file or module-by-module and let the agent work through the list.
Dependency updates
Major dependency updates often require code changes across the project. Queue the update itself as the first task, then queue fix-up tasks for each module that breaks. The sequential execution ensures the dependency is updated before the fixes begin.
Code review preparation
Before a big review, queue tasks to add inline comments explaining complex logic, ensure consistent formatting, and verify that all edge cases have tests. Wake up to a codebase that is easier to review.
The Reliability Engineering Behind It
Running agents overnight is only useful if they actually complete their work. A hung process at 1 AM means everything behind it in the queue is blocked until you manually intervene at 7 AM. SuperBuilder's reliability layer is what makes the difference between a gimmick and a production workflow.

Zombie thread detection
Sometimes a Claude Code PTY process enters a "zombie" state. The process is alive but not producing useful output -- it might be stuck in a loop, waiting for input that will never come, or producing unparseable ANSI escape codes instead of JSON.
SuperBuilder tracks the parse failure rate per thread. If a thread produces more than 10 parse failures within a 5-second window, it is flagged as corrupted and killed. This prevents stream corruption from spinning forever and blocking the queue.
Emergency kill for stuck threads
A separate mechanism monitors thread activity. If a PTY process has been idle for more than 20 seconds during active processing -- no output, no progress -- SuperBuilder's emergencyKillStuckThread() function terminates it. The queue then advances to the next task.
This is not a blunt timeout. The system distinguishes between "thinking" pauses (normal for complex tasks) and genuine stalls (the process is hung). The 20-second threshold is calibrated against real-world Claude Code behavior where even the longest thinking pauses rarely exceed 15 seconds.
Periodic zombie reaping
Every 15 seconds, a background reaper checks all tracked threads. Any thread that has been in the thread map for more than 60 seconds without activity is killed. This catches edge cases that the per-thread monitoring might miss -- for example, a thread that was marked as running but whose PTY process exited without sending a proper exit signal.
Spawning thread leak prevention
When SuperBuilder spawns a new Claude Code process, it adds the thread ID to a spawningThreadIds set. If the spawn succeeds, the ID is removed. If the spawn fails (crash, timeout, OOM), a try/finally block ensures the ID is always cleaned up. Without this, leaked IDs accumulate and eventually convince the queue that all slots are occupied, permanently blocking new tasks.
A 30-second spawn timeout acts as a backstop. If a PTY process has not started within 30 seconds, it is killed and the spawn slot is freed.
Window-independent broadcasting
A subtle but critical reliability fix: when SuperBuilder needs to notify the UI about task completion, it broadcasts to all open windows rather than targeting a specific "main window." The previous approach silently failed when the main window reference was null (common after sleep/wake cycles), which meant the renderer never learned that a task had finished. Broadcasting via BrowserWindow.getAllWindows() eliminates this failure mode.
Notifications and Monitoring
Overnight runs need a feedback mechanism. SuperBuilder provides several:
Desktop notifications
macOS native notifications fire when a task completes, when a task fails, and when the entire queue is finished. These appear in Notification Center, so you can see the summary even if you check your phone first thing in the morning.
Dock badge
The SuperBuilder dock icon shows a badge with the number of completed tasks. At a glance, you can see that 5/5 tasks finished before you even open the app.
Thread-level history
Every task's full conversation is preserved. You can read exactly what Claude did: which files it edited, what commands it ran, what errors it encountered and how it recovered. This audit trail is essential for overnight runs where you were not watching in real time.
Cost tracking
Each task tracks its token usage and estimated cost. After an overnight run, you can see the total spend across all tasks. SuperBuilder warns you if a single task exceeds $0.10 USD, giving you a chance to review expensive operations before they compound across a queue.
Tips for Better Overnight Results
After running hundreds of overnight agent sessions, here are the patterns that produce the best results:
1. Write prompts like tickets, not conversations
Overnight tasks do not have you around to clarify. Write each prompt as if it were a detailed Jira ticket: what to change, where to change it, how to verify success, and what to avoid. Include file paths, function names, and acceptance criteria.
Bad: "Fix the auth bug"
Good: "Fix the authentication timeout bug in src/middleware/auth.ts where JWT tokens are not being refreshed when they expire during long-running requests. The fix should use the refresh token stored in the session to obtain a new access token before retrying the original request. Verify by running npm test -- auth.test.ts."
2. Order tasks by dependency
If task 3 depends on the output of task 1, put them in the right order. SuperBuilder executes sequentially, so earlier tasks' changes are on disk when later tasks start. But do not create long dependency chains -- prefer independent tasks that can succeed or fail without affecting each other.
3. Include verification steps in the prompt
Tell the agent to run tests, lint checks, or type checks after making changes. This catches errors during the overnight run rather than leaving them for your morning review. A task that ends with "run npm test and fix any failures" is far more likely to produce clean results.
4. Start with a clean working tree
Before queuing overnight tasks, commit or stash your current changes. The agent's modifications are easier to review when they start from a known state. It also prevents merge conflicts between your in-progress work and the agent's changes.
5. Use separate branches per task
For larger runs, instruct each task to create its own branch. This gives you clean diffs for review and lets you cherry-pick the good results while discarding tasks that went sideways.
6. Test with one task first
Before queuing a full overnight run, run a single representative task and review the results. This validates that your prompt style, project configuration, and SuperBuilder setup all work correctly. One successful test run gives you confidence to queue ten tasks and walk away.
7. Keep tasks focused
A 50-line prompt trying to accomplish five different things will produce worse results than five 10-line prompts that each accomplish one thing. The agent performs better with clear, scoped objectives. Decompose your work into the smallest independent units.
Getting Started with SuperBuilder
SuperBuilder is free, open-source, and available for macOS. Getting set up takes about two minutes:
- Download SuperBuilder from superbuilder.sh
- Open the app and point it at your project directory
- Make sure you have an active Claude Code subscription (Max plan recommended for overnight runs due to higher rate limits)
- Queue your first task and watch it execute
- Once you are confident in the setup, queue a batch and step away
The task queue, reliability engineering, notifications, and cost tracking are all included out of the box. No configuration files, no Docker containers, no self-hosting infrastructure.
If you are already using Claude Code in the terminal and want to unlock claude code automation for unattended work, SuperBuilder is the bridge between a powerful CLI and a production-grade agent orchestration system.
FAQ
Can I schedule tasks to run at a specific time?
SuperBuilder's queue starts processing immediately when you initiate it. For time-based scheduling, you can use your system's built-in scheduling (like macOS Shortcuts or cron) to trigger SuperBuilder at a specific time, or simply start the queue when you are ready to step away.
What happens if my computer goes to sleep?
SuperBuilder keeps the Electron process alive and prevents sleep while tasks are running. If your Mac does sleep (lid close, for example), the queue pauses and resumes when the system wakes. No tasks are lost.
How many tasks can I queue?
There is no hard limit. The queue is backed by SQLite, so it handles hundreds of tasks without issue. The practical limit is your Claude Code usage tier -- Max plan users have the highest rate limits and can run the most tasks per overnight session.
Does this work with Claude Code's API key or subscription?
SuperBuilder uses your existing Claude Code installation and subscription. It spawns Claude Code as a subprocess, so any authentication method you have configured (subscription, API key) works automatically.
Is my code sent to SuperBuilder's servers?
No. SuperBuilder is fully local. Your code stays on your machine. The app communicates only with Anthropic's API through Claude Code, exactly as the CLI does. There are no SuperBuilder servers involved.
Can I use this with other AI coding tools?
SuperBuilder is purpose-built for Claude Code. The task queue, reliability monitoring, and session management are all designed around Claude Code's specific behaviors and output format. Support for additional agents may come in the future.
What if a task produces bad results?
Each task runs in its own session, and all changes are made to your local filesystem. You can review diffs, revert changes with git, or discard individual tasks. Nothing is pushed to remote repositories unless the task's prompt explicitly instructs the agent to do so.
How much does an overnight run cost?
Cost depends on your Claude plan and the complexity of tasks. On the Max plan ($100-200/month), you get a generous rate limit that covers most overnight workloads. SuperBuilder tracks per-task costs so you can monitor spend. A typical 5-task overnight run on a medium-complexity codebase uses roughly $2-8 of API credits on usage-based plans.
Ready to put your AI coding agent to work while you sleep? Download SuperBuilder and start queuing tasks tonight. It is free, open-source, and built for developers who want to get more out of Claude Code without babysitting a terminal.