Claude Code Routines: Cloud Jobs, GitHub Triggers, Human Review

Lachlan Reed

[warmly] Welcome to the show. James, April 14, 2026: Anthropic drops Claude Code Routines as a research preview, and the bit that made me sit up was dead simple -- the job runs on Anthropic-managed cloud infrastructure. Not on your laptop. Not on some crusty local daemon you forgot was running. Your machine can go to sleep, you can shut the lid, wander off, and the work keeps going.

James Turner

[curious] April 14, 2026 is gonna stick for me because that is a REAL line in the sand. You're saying the old setup literally died if the laptop slept? Like, Wi-Fi hiccup at 2 a.m., game over?

Lachlan Reed

Exactly. That was the brittle bit. If your machine slept, lost Wi-Fi, got restarted, battery carked it -- the automation died with it. Plenty of us have done the grim little ritual of leaving a laptop open overnight for a dependency audit or a long repo task, like it's a campfire you can't let go out. Routines decouple execution from hardware for the first time, and that changes the whole feel of it.

James Turner

[laughs] The campfire image is painfully accurate. I've absolutely had that move where the screen is dimmed, charger plugged in, and you're like, "Nobody touch THIS machine." But okay -- if it lives in Anthropic's cloud now, the upside is obvious. The weird part is also obvious: it's running somewhere you can't see.

Lachlan Reed

[reflective] Yeah, that's the split emotion. Relief and a tiny bit of the heebie-jeebies. The best mental model I've found is: don't think "smarter script." Think "saved Claude Code job with a home in the cloud." That's different. A script feels like a thing you launch from your desk. This feels more like you've built a worker, parked it somewhere else, and now you're sending it jobs.

James Turner

Wait -- "saved Claude Code job with a home in the cloud" is the phrase I'd underline. Because that means the workflow isn't me babysitting a terminal anymore. It's me defining a repeatable session that can wake up later, right?

Lachlan Reed

That's it. And once you think of it that way, workflows that used to feel a bit too flaky start sounding realistic. Not because the model got magic powers overnight, but because the execution environment stopped being your personal laptop balanced on the edge of sleep mode. It's a small shift on paper. In practice, mate, it's the difference between "maybe I'll try this once" and "yeah, this can be part of how I work."

James Turner

[skeptical] I like the convenience. I do NOT automatically trust the convenience. Because when something moves off your machine, you also lose a kind of gut-level visibility. You can't glance at a terminal window and go, okay, I see what's happening. So the promise here is freedom from hardware fragility. The price is, at least a little, abstraction.

Lachlan Reed

[softly] And that's the tension for the whole thing, honestly. For anyone who's ever nursed an overnight task through dodgy Wi-Fi, this is a blessing. For anyone who's careful about where code runs and how, it's also a signal: stop treating this like a cute local hack. It's becoming something a bit more serious.

James Turner

[energized] Okay, so if the worker lives in the cloud, the next question is: how do you wake it up? There are three paths, and they get progressively more interesting. The simplest is scheduled triggers -- hourly, nightly, weekly. You can create those at claude.ai/code/routines or just use the /schedule command in the CLI.

Lachlan Reed

Hourly, nightly, weekly -- that's already enough for heaps of boring chores. Like, nightly is the magic one for me. That's the "check the house while I'm asleep" schedule. And I like that it's both in the site and the CLI, because half the battle with tooling is whether you'll actually use it where you already live.

James Turner

Right. Then the programmable one is the API trigger. Every routine gets its own HTTP endpoint and its own dedicated bearer token. You send a POST, it spins up a session, runs the prompt, and gives you back a session URL that you can open live.

Lachlan Reed

[questioning tone] That session URL is the bit I'd circle. So it's not just "fire and forget." You can actually jump into the run and inspect it?

James Turner

Yeah -- that's what makes it feel operational instead of opaque. And there's another nice detail: the POST body accepts a text field that gets appended as a one-shot user turn. That's huge. Because now the routine isn't locked as some frozen static job. It's a reusable agent template with just-in-time context.

Lachlan Reed

[textually amused][chuckles] "One-shot user turn" sounds very AI-lab, but the practical version is dead clear: same worker, new note slipped under the door. Like, "run the release checks for version 2.4.1" or "look at THIS incident." That's much more flexible than a dumb cron script.

James Turner

Exactly. Same routine, fresh context per invocation. Then the third trigger is the one ops people are gonna care about most: GitHub events. Pull requests, pushes, releases -- those can wake a routine. But there is one setup gotcha that matters a LOT: the Claude GitHub App has to be installed.

Lachlan Reed

[responds quickly] And this is where people will trip, yeah? Because /web-setup sounds like, "sweet, GitHub is wired up." But that's not enough for webhooks.

James Turner

Yep. /web-setup only grants repo cloning access. It does NOT grant webhook power. If you want PRs or pushes or releases to trigger the routine, the GitHub App is the thing that gives you that event plumbing.

Lachlan Reed

That distinction -- cloning versus webhook power -- is the sort of tiny setup detail that eats an afternoon. You think the ute's got fuel, then realize the hose isn't connected. So, simple schedule if you want regular chores, API if you want programmable context, GitHub events if you want it wired into the repo's actual heartbeat.