Always-on Claude Code: an Openclaw replacement

The promise vs reality of Openclaw

Openclaw promises to be an AI assistant that “actually does things”. Allowing you to interact with it on-the-go from your phone, while working in the background for you and running scheduled tasks. One of its biggest features being memory. It can actually remember things about you and the things you’re working on. It’s a promising idea, so I dived in.

I may share a more detailed experience with Openclaw another time, suffice to say, a lot of time was spent working around the system, not with it. Patching holes in memory, working without a UI (as it never really worked), remoting into my Raspberry Pi (which was running my Openclaw instance) to debug. Things may have changed since my initial usage, but at the time, unless you were running the latest Opus model, it was difficult to get quality outputs.

A lot of time was spent working around the system, not with it.

Despite that, the experience gave me a glimpse into something exciting. The premise was worth pursuing, so it made me wonder whether I actually needed a separate service for it, or whether I could build essentially the same experience, whilst leveraging my existing Claude plan (seeing as though Anthropic was blocking OAuth usage with Openclaw[01]).

After a few months of running my own version, the answer is that you can. A cheap always-on Mini PC, a shared GitHub repo, and a handful of scheduled tasks gets you the same core benefits:

• Scheduled tasks that run without you: automations firing daily whether or not your laptop is on.
• Remote sessions from your phone: connect to a live session on the way to work, send a task, and have results waiting when you arrive.
• Context that follows the work, not the device: both machines share the same memory store, so there’s no “wait, which machine did I do that on?” when you switch.

No new subscription, no separate service. This is how I built it. However, it isn’t without its own challenges. You now have to maintain the Openclaw layer. The benefit being you can control the complexity and security.

If you want to set this up yourself, the instructions can be found at github.com/yesterdayshero/always-on-claude-code.

What you actually want from “always on”

The benefits, before diving into the architecture.

Scheduled jobs that run when your computer is off: A daily check that runs at 3pm whether or not I remember it exists. A memory consolidation job that processes today’s session notes into long-term memory every day. The kind of work that’s too small to think about individually, but ladders up into something useful when it runs automatically.

Remote sessions from your phone: Your ideas don’t always come to you when you’re in front of your computer. Which means at best you end up writing random notes or setting reminders, and at worst you just forget things. The Claude Code mobile app, connected to a live session on the Mini PC, means I can send a quick task when it comes to mind.

Memory and context that follow the work, not the device: Both machines read from the same memory store. There’s no “wait, did I do that on the laptop or the Mini PC?”. This is what makes the remote sessions actually useful, as for the most part, you aren’t talking to two different machines.

Those are the same things Openclaw is promising. The difference is who owns the underlying experience.

How the two machines fit together

My laptop is the daily driver. It’s the machine I actually sit at and do the bulk of my work on. The Mini PC runs quietly in the background, handling scheduled tasks and staying available for remote sessions while my laptop is off.

The two machines don’t need to talk to each other directly. Everything routes through GitHub: the laptop pushes changes, the Mini PC pulls them down. The Mini PC pushes its own work back up, and the laptop pulls that too. It’s a clean separation: each machine does its own work and syncs through the same shared repo.

GitHub is the sync layer. The pattern works the same regardless of how your home network is arranged.

The reason my machines aren’t talking directly is that I have my Mini PC on a separate IoT VLAN. It acts as a home server for things other than Claude. Having the machines on separate networks isn’t required. You can run this setup with everything on a simple home network, and it’s actually a bit more convenient for things like previewing a local dev server. The key point is that GitHub handles the sync regardless of how you’ve arranged things at home.

One git repo, two machines, shared path

Both machines store the Claude Code repo at the same path:

C:\Users\alex\Claude Code

That’s the main folder where everything lives. It’s essentially my working directory for all things I want to do with Claude Code. Remember, we need a folder that can be shared with both devices, so that things like memory and the projects you’re working on are shared by both.

We need a folder that can be shared with both devices, so that things like memory and the projects you’re working on are shared by both.

Claude Code by default reads its settings from a different location: ~/.claude (which on Windows resolves to C:\Users\alex\.claude). To keep both pointing at the same files without copying anything around, I use a Windows directory junction, a built-in feature that lets two folder paths resolve to the same underlying location[02].

mklink /J "C:\Users\alex\.claude" "C:\Users\alex\Claude Code"

After this, both paths point to the same place. Claude Code finds what it expects at ~/.claude; everything else uses the main repo path. It’s a one-time setup step, not something you need to think about again.

The only constraint is that both folders need to be on the same drive.

Same OS on both ends

A Raspberry Pi would be cheaper, but it would introduce a split between Linux and Windows: different folder structures, different commands, different setup steps for each tool. Running the same Windows 11 on both machines means identical paths, identical commands, and identical memory references. The setup steps I ran on the Mini PC are the same ones I’d run on a new laptop.

There’s also a practical consideration around memory. A Pi with 4GB doesn’t leave much headroom once the operating system is accounted for. A modest Mini PC with 16GB has plenty to spare. That headroom matters when Claude Code is running memory consolidation or handling multiple scheduled tasks at once.

How the sync actually runs

The Mini PC has a single script (claude-sync.ps1) that runs every few hours and on boot. It does three things:

1. Pull any changes from GitHub. It uses a clean merge approach where possible. If remote changes can be added on top of local ones without any conflicts, it does that. If there is local work that needs to fit in alongside remote changes, it replays the local changes on top rather than creating a merge entry, which keeps the history readable instead of filling up with automatic merge commits every few hours.
2. Push any local changes, usually just the daily memory files the Mini PC has updated. Along with anything I may have been working on remotely.
3. Write and push a status file (health/status.json) so the laptop can check whether the Mini PC is healthy.

The schedule runs six times a day (07:00, 10:00, 13:00, 16:00, 19:00, 23:00) plus a trigger 60 seconds after boot (in case of a Windows update or restart). Six times is enough that any updates from overnight automated tasks are available on the laptop before a morning session starts, without the script running constantly for no good reason.

If a sync fails, the script posts to a Discord webhook, a simple way to send a notification that doesn’t need any running software to receive it.

Health monitoring

Every successful sync, the Mini PC writes a small status file:

{
  "last_sync": "2026-05-02T07:00:12+00:00",
  "status": "OK",
  "hostname": "MINI-PC"
}

It commits and pushes that file alongside everything else. The laptop can check Mini PC status with one line:

git pull && cat health/status.json

If the timestamp is more than eight hours old, or status shows FAILED, something’s gone wrong. The first place to check is Discord: the sync script will have posted an error message there when it failed. After that, check the Task Scheduler log on the Mini PC itself to see exactly what failed and when. In reality, I just ask Claude to see what went wrong and it will check the logs for a diagnosis and fix if one is needed.

What runs while my laptop is closed

Sync (6× daily plus boot)

The script above. Everything else depends on this being reliable.

Memory consolidation (8am daily, plus a Sunday deeper run)

During every session, Claude Code writes raw notes about what was done: decisions, things that didn’t work, patterns worth keeping. Consolidation processes those notes into structured long-term memory that both machines read from. When you open a session in the morning, it already has the previous day’s context integrated, regardless of which machine you sit down at. The weekly process does some of the maintenance tasks such as archiving old or unused memories, so as not to bloat the context load at the start of every session.

OAuth heartbeat (9am, 9pm)

Claude Code’s login token expires after a period of inactivity. An expired token can prevent remote sessions staying open if they’re inactive for too long. The fix is a lightweight job that keeps the token active by running twice a day with a minimal prompt. It uses the cheapest available model.

IMAX ticket checker (3pm daily)

A small job that checks IMAX Sydney’s listings for a film I’ve been waiting to see, and pings Discord when pre-sale dates appear. It’s been running for months and it’s quietly one of the most useful tasks. The point of a task like this isn’t just the task itself. It allows you to test out scheduled tasks run as expected, see whether you can leverage cheaper models, try out Discord webhooks.

The IMAX checker is a useful early test for the whole setup. It’s small enough to debug in an afternoon, scheduled regularly enough that you’ll notice if anything breaks, and it posts to Discord on both success and failure. A good way to verify everything is wired together correctly before you rely on it for anything more important.

Obsidian vault (Second Brain) automation

Four jobs that keep the Second Brain tidy without manual work. These all happen in the early hours of the morning so everything is ready to go by the time I wake up:

• Daily: process new notes in the inbox: categorise, wikilink, populate movies/tv shows and books I’m consuming. The real gold here is I don’t have to manually find images or links to media, it’s all populated for me overnight.
• Sunday morning: generate a weekly summary covering the week’s events, themes, personal, career and a look at events coming up next week.
• First of the month: generate a monthly summary that aggregates the weekly notes and generates themes.
• Once a month: run an audit of old notes for stale links, missing tags, and orphaned files.

This is the heaviest user of the Mini PC’s time, and the thing I’d most struggle to replicate manually. Not because it’s difficult to do, but due to the time it would take me to replicate it. I would likely stop organising my notes after a couple of months.

I think the real value here isn’t using Obsidian to empower Claude Code, it’s using it to empower you.

Working remotely

From the Claude Code mobile app

Run /remote-control in any Claude Code session on the Mini PC to access it through the iOS/Android apps[03].

This is the workflow I use most. Open the app on the train, fire off a quick task, and let the Mini PC handle it.

CAUTION: if you /clear the session, you will lose the remote connection and need to re-enable it from the Mini PC.

From Discord

Discord plays two roles in the setup and they work quite differently.

Webhook notifications: When a sync fails, a task is completed, or anything else worth knowing happens, the Mini PC posts a message to a Discord channel directly. This is one-way, requires no running session, and doesn’t need any additional configuration beyond a webhook URL from Discord.

Interactive sessions: With an MCP server connected to a live Claude Code session, you can direct message a Discord bot and Claude will respond in the same thread[04]. Useful for tasks that don’t need a long back-and-forth.

Honest limits

The remote workflow is genuinely useful, but it has limits worth knowing about:

1. One session at a time: You generally can’t run parallel sessions in the same Claude Code instance. Although you can cheat a little and have a Terminal and Claude Code App session both running on the Mini PC at the same time.
2. Interactive commands stay at the terminal: Anything that opens a menu or picker (/mcp, /plugin, /resume) doesn’t work remotely.
3. Clearing a session ends the remote connection: /clear works from mobile, but it stops the remote connection. To reconnect, you’d need to go to the Mini PC and run /remote-control again.
4. Discord bot needs the remote session to stay active: If the Claude Code session that’s linked to the Discord bot goes inactive, the channel goes dark and you won’t know until you try to message and don’t get a response.
5. Reboots end running sessions: If the machine restarts for any reason (a Windows update, a power cut), any active remote session ends. Scheduled tasks pick back up automatically on their next trigger. It’s worth configuring Windows Active Hours to try to avoid automatic restarts for Windows updates during times you’re likely to have a session running.

Tricky bits

Nested project repos

Most of my bigger projects have their own GitHub repos. If a folder inside the main Claude Code repo is itself a separate git repository, git will quietly stop tracking the files inside it. This can get a little confusing. And it also breaks the syncing with the Mini PC.

You can still store the project folders inside your main Claude Code directory by ensuring they’re .gitignored. To make sure they get pulled onto the Mini PC, a list of repos lives at scripts/project-repos.txt. When the sync script runs on its schedule, it pulls each project alongside the main repo. A bit more up-front configuration and consideration. Can still leave you with a bit of lag if a newly created project hasn’t synced over to the Mini PC yet, but still workable.

Concurrent sessions

Don’t run the same project on both machines at the same time. Memory writes will conflict, session notes will land out of order, and handoff files will overwrite each other.

In practice, this is less constraining than it sounds. The laptop is the interactive seat. The Mini PC’s writes are scheduled, predictable, and almost always on different files: long-term memory, health status, project automations the laptop rarely touches.

Handoff between sessions

When you finish a session, Claude’s closing hook automatically updates two files before pushing: a detailed episode note capturing what was done, any decisions made, and anything that went wrong; and a handoff file that the next session reads to orient itself. You trigger this by saying something like “done for today” or “wrap up”. Claude handles the writing and the commit. An important thing to remember is to sign off at the end of a session.

I recently ran into an issue where the episodes and handoff were running a little long, as I hadn’t explicitly set a guide on the length in my CLAUDE.md instructions. I noticed the bloat when it was taking longer to write the episode and handoff, than it took to complete a small task. Adding an explicit length guide to my CLAUDE.md cleared it up.

Owning the box and the architecture

The practical case for this setup comes down to a few things that compound over time.

Scheduled tasks that used to require you to be at a computer, at the right moment, remembering to run them. They just run. Memory consolidation means every session starts with full context, regardless of which machine you’re on or how long it’s been since the last one. Remote sessions from your phone close the gap between having an idea on the way to work and having a result waiting when you sit down. Simpler, repetitive jobs can run on cheaper models at negligible cost, which means the bar for “is this worth automating?” gets lower.

The hardware is a one-time cost, and everything after that runs against the Claude plan you’re already on. No additional service in the chain, you built the process, and nothing about the setup changes unless you change it.

Is it for you?

I’d love to say it only took a weekend to set up and I haven’t touched it since, but in reality, there’ll be some tinkering every now and then to make sure it’s working effectively and efficiently. Some things you just won’t notice until you’ve been up and running for a while. I took this on relatively early in my journey into AI, as I had seen the advantages of what Openclaw promised. I probably would have done a few things differently if I went back and did it again. The benefit of this implementation wasn’t just the functionality itself, but what I was able to learn during the process.

Set it up yourself

If you want the same thing on your own machines, I created a public template at github.com/yesterdayshero/always-on-claude-code. The sync scripts, scheduled task definitions, and step-by-step setup instructions are all there. Including some examples of the scheduled tasks I run for inspiration.