Why My AI OS Survived Anthropic's Harness Lockdown

The Day Anthropic Dropped the Hammer

On April 4th, 2026, Anthropic discontinued support for third-party harnesses using Claude Code subscriptions. If you were running OpenClaw or anything similar that acted as an OAuth intermediary to proxy your subscription credentials, you had a choice to make: migrate to pay-as-you-go API billing, rebuild your setup, or switch providers entirely. A lot of people got caught off guard.

I was completely unaffected.

I have all the benefit of OpenClaw. I've actually even got a pretty decent TypeScript UI that I use for observability into all of my automations. It's fully custom, cherry-picked from what OpenClaw does that I actually want to do. And the reason it survived isn't because it flew under the radar. It's because the architecture is genuinely different from what Anthropic targeted.

What Makes My Architecture Different?

I'll be honest, I kind of lucked into this. The architecture we chose is technically not doing what OpenClaw does. The specific difference matters: OpenClaw acts as a third-party OAuth harness that proxies your Claude Code subscription credentials. My system calls claude -p as a subprocess. That's the official CLI binary, running under my local login, on my machine. One is a harness sitting between you and Anthropic. The other is just using the product.

It runs all on one machine. Single user. Single subscription. Every Claude Code process spawns from the same local login, the same way it would if I was sitting at the keyboard typing commands myself. The automated agents and my interactive sessions all draw from the same pool. That's compliant because it's exactly how Claude Code was designed to be used.

The other half of it was a bunch of networking work I did to make single-machine development actually practical. Hardening my home network, setting up WireGuard, optimizing my VPN so I can work remotely without cloning repos or switching machines. That infrastructure investment is what made the one-machine constraint livable instead of painful.

The Old M1 Mac That Became the Engine

I wanted to be really close to the engine of my AI operating system. So what I did was take my old M1 Mac, the machine I discontinued when I upgraded my daily driver workstation. Nothing was wrong with it. I completely reformatted it and set it up as a dedicated machine for Gus, my AI agent.

Back in the first wave of OpenClaw, everybody was loading up Mac Minis. People were giving an AI agent full filesystem access, and that made a lot of folks nervous. Reasonable reaction. Set it up on a completely separate machine that doesn't have access to all your services, test it in a sandbox until you trust the security model. I did the same thing with my old M1. Rather than buy a Mac Mini, I just had this old computer laying around, so I used it.

Having a physical machine sitting on my desk with a monitor and keyboard turned out to be way more valuable than I expected. Initially I thought the only benefit was going to be easy setup: give Gus his own Google account, his own everything, harden one thing at a time. But working two computers at once, being right there next to it, that changed how I built the whole system.

Cherry-Picking Instead of Chasing Parity

While I'm building this, I've got two projects open. I'm following the open source repository for OpenClaw, and I'm following the development of the spec and all the skills in Claude Code. The skills are all just markdown files, plainly readable, no obfuscation at all. So I'm already substantially reverse engineering it just from the spec, and building my own thing on top.

There were at least two things making my setup develop as its own thing rather than a clone. First, I was developing it for me. My direct personal assistant. No multi-tenant enterprise concerns, no managing separate subscriptions. Second, because the machine was right there, I was directly overseeing every terminal. Running many agents at once, but all under my own login, on one box.

The whole time, I'm thinking I'm a failure if I can't keep parity with OpenClaw and Claude Code. My agent kept correcting me: "No, we're not keeping parity, but it's okay. We don't want to." And I'm just like, whatever dude, I'm seeing parity to the point that I care about. Not even realizing that cherry-picking the features you want is just not what parity means. But that's exactly what saved me. I built what I needed, not what they built.

How Does the Remote Workflow Actually Work?

It is a limiting factor, I won't pretend otherwise. My automated agentic workflows and my interactive dev sessions share the same Claude Max rate limit pool. If I'm doing heavy development work at the same time Gus is running a bunch of pipelines, they compete. I'd probably get throttled. That's a real constraint.

But I put all of my repos for all of my current development work on Gus. That started out as laziness, and then I realized no, this is just efficiency. It's right there next to Gus. It's a lot easier to have it already detected under Gus's memory system than to have Gus reach out to my machine. Plus there are security concerns. That's another attack surface to harden and monitor and manage.

The directory where all my working repos live is shared on the LAN with Samba. I connect through SSH with Cursor. And one thing I thought was going to be a dealbreaker: Claude Code is really handy when you can take screenshots and drop them into the terminal, or a client provides images and you need to drop those directly in. I struggled with this for a bit, but because the repo directory is shared on the LAN, I can just open up Finder, drag images over into the other Finder window, they show up in the file system, and then I drag from the Cursor file system right into the terminal. Almost no extra friction.

Now the dealbreaker you're probably already thinking of: what happens when I take my laptop somewhere? I don't have access to any of my files. Have to clone the repo and start fresh. Nope. Because I did all that work to set up WireGuard, I can just tunnel right into my LAN. SSH from Cursor into the repo folder on Gus, use Finder too. Everything works when I'm remote, as long as I can connect through the VPN. The only remaining gap is internet redundancy at home, unless I'm there with my cell phone to use as a hotspot.

What I'm Not Immune To

I want to be honest about the vulnerabilities here. My architecture is compliant today. That doesn't mean it's bulletproof forever. If Anthropic decides to restrict claude -p subprocess usage, or adds rate limits that distinguish between interactive and automated calls, I'd be affected too. I survived this policy change. That's not the same thing as being immune to the next one.

There's also the cost question. I'm on Claude Max, which is not cheap. For some people reading this, pay-as-you-go API billing might actually be cheaper depending on their usage. The subscription math only works in my favor because I'm running enough automated pipelines that per-call billing would add up fast. If you're just doing interactive development, run the numbers before assuming a subscription is the move.

One Machine, One Login

So now I don't have to worry about logging in with my Claude Code subscription on another machine and killing all my automations. The only place I'm logged into Claude Code is on that machine. It's not optimal. It still sucks that Anthropic did this. But the level of functionality I have is actually really powerful. All of my client workflows that I'm currently managing were already running on Gus anyway.

I am going to start moving toward setting up individual AI operating systems for other people. That's its own challenge, because each person would need their own subscription on their own machine. The moment you start managing multiple users through a shared system, you're right back into harness territory. So the one-person-one-machine model has to scale horizontally, not vertically. I need a way to share common automations without reinventing the wheel every time, but each instance has to be self-contained.

For now, my system survived because I built it for one person, ran it on one machine, and stayed close to the metal. I got lucky that the architecture I chose for practical reasons turned out to be the one that didn't break when the platform shifted. But luck isn't a strategy. I'm watching what Anthropic does next, and I'd recommend you do the same.