Book AI coding agents on a real calendar. Clockwork runs them unattended in sandboxed git worktrees on your Mac, pauses for approval when something looks risky, and files a report with the actual dollar cost. Bring your own key or ride your existing subscription. Schedule recurring agent jobs on a real calendar, run them unattended in isolated sandboxes, and review honest reports.
I built Clockwork because I was paying for Claude capacity that sat idle about 18 hours a day, while I re-typed the same repo chores every week by hand.
The idea is simple: if an agent can do the work, give it a workday. A slot on the calendar, a budget, permission rules, and a report when it's done.
Trusting something to run while I'm asleep meant the boring parts had to be real: • Runs execute inside a macOS Seatbelt sandbox, in a per-run git worktree. Writes are confined to that worktree. • The run environment is an allowlist, so SSH_AUTH_SOCK and your provider tokens never reach the agent process. • Risky steps pause and ask instead of failing silently or ploughing on. • Hard budget caps in dollars, turn limits and wall-clock timeouts, enforced by the supervisor rather than the model's good intentions. • You can check all of that rather than believe it - the sandbox, the credential deny list and the env allowlist are Apache-2.0 in the repo, and the tests write a fake secret into `~/.ssh` and `~/.aws`, then run `cat` inside a real sandbox and assert it fails. The rest of the app is source-available under a proprietary licence, so please don't call it open source; I'd rather be precise than flattering.
Honest limits, up front: • Runs need your Mac awake. It holds off idle sleep during booked windows when plugged in, and tells you loudly when a miss happened instead of hiding it. • It isn't notarised yet — an Apple certificate is $99/year and this is an early build - so you clear the quarantine flag by hand. The install docs say exactly why. • Apple silicon only, for now. It's free. There's no paid tier you can buy today. I'd genuinely like to hear what you'd want before trusting an agent with more of your week.
Report
Congrats on your PH launch! Love the OSS spirit!
I am running a lot of agents and unfortunately I have to babysit them and I often go to bed late because I want to just make sure I get one more task going before I go to bed. Clockwork seems to fill this gap for me so I will definitely try it!
I am curious how Clockwork handles a recurring slot when the previous run is still waiting for approval: skip it, queue it, or start another isolated worktree?
@simon_liang_1 Thanks! That’s exactly the kind of babysitting Clockwork is meant to eliminate 😄
For recurring slots, Clockwork doesn’t start another run while the previous one is still waiting for approval. The next scheduled run is skipped rather than queued or creating another isolated worktree. The idea is to avoid piling up agent work that still needs human attention. Once the current run is approved/completed, the next scheduled slot can proceed normally.
Report
claude capacity sitting idle abt 18 hours a day, yeah thats real. if it pauses for approval at 2am does the slot just die or hold till i say yes
@niveditha_patluri1 Yep - if it pauses for approval at 2am, the slot holds. It doesn’t die just because you’re asleep. 😄 The agent stays paused until you approve/reject it, and Clockwork won’t start another run for that recurring slot while the previous one is still awaiting approval.
the wall-clock timeout is the part I'd want to understand better. if an agent is mid-commit or mid-rebase when its slot runs out, does the supervisor let it finish the git operation before killing it, or does it cut the process wherever it happens to be and leave the worktree in a half-done state for the next run to deal with
@galdayan Good question - the wall-clock timeout is a hard boundary for the agent process. Clockwork doesn’t try to detect whether it’s currently in a git commit/rebase and extend the slot.
When the slot expires, the supervisor terminates the process, so an operation in progress can potentially be interrupted. The worktree is then preserved rather than discarded, allowing the next run to inspect and recover from the state. That said, I agree this is an important edge case, especially around rebases and other non-idempotent git operations. It’s something we’re being careful about because timeout shouldn’t mean leave the repo in a broken state
Clockwork
Hello PH Folks👋 My Self Vimox Shah,
I built Clockwork because I was paying for Claude capacity that sat idle about 18 hours a day, while I re-typed the same repo chores every week by hand.
The idea is simple: if an agent can do the work, give it a workday. A slot on the calendar, a budget, permission rules, and a report when it's done.
Trusting something to run while I'm asleep meant the boring parts had to be
real:
• Runs execute inside a macOS Seatbelt sandbox, in a per-run git worktree. Writes are confined to that worktree.
• The run environment is an allowlist, so SSH_AUTH_SOCK and your provider tokens never reach the agent process.
• Risky steps pause and ask instead of failing silently or ploughing on.
• Hard budget caps in dollars, turn limits and wall-clock timeouts, enforced by the supervisor rather than the model's good intentions.
• You can check all of that rather than believe it - the sandbox, the credential
deny list and the env allowlist are Apache-2.0 in the repo, and the tests write a fake secret into `~/.ssh` and `~/.aws`, then run `cat` inside a real sandbox and assert it fails. The rest of the app is source-available under a proprietary licence, so please don't call it open source; I'd rather be precise than flattering.
Honest limits, up front:
• Runs need your Mac awake. It holds off idle sleep during booked windows when
plugged in, and tells you loudly when a miss happened instead of hiding it.
• It isn't notarised yet — an Apple certificate is $99/year and this is an
early build - so you clear the quarantine flag by hand. The install docs say exactly why.
• Apple silicon only, for now. It's free. There's no paid tier you can buy today. I'd genuinely like to hear what you'd want before trusting an agent with more of your week.
Congrats on your PH launch! Love the OSS spirit!
I am running a lot of agents and unfortunately I have to babysit them and I often go to bed late because I want to just make sure I get one more task going before I go to bed. Clockwork seems to fill this gap for me so I will definitely try it!
I am curious how Clockwork handles a recurring slot when the previous run is still waiting for approval: skip it, queue it, or start another isolated worktree?
Clockwork
@simon_liang_1 Thanks! That’s exactly the kind of babysitting Clockwork is meant to eliminate 😄
For recurring slots, Clockwork doesn’t start another run while the previous one is still waiting for approval. The next scheduled run is skipped rather than queued or creating another isolated worktree. The idea is to avoid piling up agent work that still needs human attention. Once the current run is approved/completed, the next scheduled slot can proceed normally.
claude capacity sitting idle abt 18 hours a day, yeah thats real. if it pauses for approval at 2am does the slot just die or hold till i say yes
Clockwork
@niveditha_patluri1 Yep - if it pauses for approval at 2am, the slot holds. It doesn’t die just because you’re asleep. 😄 The agent stays paused until you approve/reject it, and Clockwork won’t start another run for that recurring slot while the previous one is still awaiting approval.
Dial
the wall-clock timeout is the part I'd want to understand better. if an agent is mid-commit or mid-rebase when its slot runs out, does the supervisor let it finish the git operation before killing it, or does it cut the process wherever it happens to be and leave the worktree in a half-done state for the next run to deal with
Clockwork
@galdayan Good question - the wall-clock timeout is a hard boundary for the agent process. Clockwork doesn’t try to detect whether it’s currently in a git commit/rebase and extend the slot.
When the slot expires, the supervisor terminates the process, so an operation in progress can potentially be interrupted. The worktree is then preserved rather than discarded, allowing the next run to inspect and recover from the state. That said, I agree this is an important edge case, especially around rebases and other non-idempotent git operations. It’s something we’re being careful about because timeout shouldn’t mean leave the repo in a broken state