How I Run Codsworth

I’ve been meaning to play with AI a bit more, but in a way that’s actually useful.

A lot of the agent stuff you see online seems to go straight to the most chaotic version of the idea. Give it access to everything, wire it into your whole life, let it loose, and then act surprised when it starts doing weird stuff. I wasn’t especially interested in that.

What I wanted was something a bit smaller and more practical. Something that could do real jobs for me without needing access to my entire digital life. So I set up Codsworth, my OpenClaw assistant, in a way that’s deliberately simple and fairly constrained.

The name is a Fallout 4 reference, which felt about right. If I’m going to have a robot-butler-ish thing hanging around on an always-on machine at home, it may as well commit to the bit.

It runs on a Mac Mini at home. It’s always on, it’s local, and it means the whole thing can just sit there and exist without depending on whether my laptop is open or not. There wasn’t any grand architectural thinking behind that bit. I just wanted it somewhere stable.

The more important part was giving it its own separate macOS user account.

That account has no admin permissions, which is really the whole point. It’s not my normal account, it can’t get into my main home directory, and it doesn’t have access to all the usual stuff I’m signed into. I’ve kept it deliberately clean. If an agent can act as that user, then the obvious thing to do is make that user as uninteresting as possible.

So it’s not signed into my normal apps, it doesn’t have access to anything personal, and it basically just exists to run OpenClaw and do a couple of specific jobs.

In practice, Codsworth only has access to two meaningful external things.

The first is OpenAI, via the OAuth bit that OpenClaw handles during setup. I’m not going to pretend this post needs to go deep on that, because it really doesn’t. The important part is just that it can access the model, and that’s all I need from that side of things.

The second is GitHub, using a personal access token that’s scoped just to my blog repo, pennai.co.uk. That means it can create branches, commit changes, push them, open PRs, and merge them, but only in that repo. That’s enough to make it useful, without giving it access to a load of unrelated things.

That’s basically the model for the whole setup. Keep the machine-level access limited by the macOS user. Keep the online access limited by what that user is signed into. Keep the GitHub access limited to the one repo I actually want help with.

I talk to it through WhatsApp, which I like mostly because it makes the whole thing feel normal. I can just message it. There’s no separate app I need to remember to open and no feeling that I’m logging into some special AI Control Centre. It just lives in the same place I already message people. OpenClaw handles that side of things, and it was all straightforward enough that it’s not the interesting part.

The interesting part is the workflow sitting on top of that.

For blog posts on pennai.co.uk, I’ve got a custom flow set up. If I want to start a post, I message Codsworth with Blog: and whatever the topic is. That kicks it into blog mode rather than just treating it like a general chat.

It then sends back an intake card with title options, the angle, target reader, key questions, an outline, and a suggested length. I like that bit because it forces a pause before the drafting starts. It has to show me what it thinks it’s doing before it disappears off and writes a full post in the wrong direction.

That’s the first approval gate: I reply with “Outline approved”.

Once that happens, it writes the draft in my tone and I can tweak it, send edits back, ask for changes, whatever. That part can loop a few times if needed. I’m not trying to fully automate writing here. I just want help with the annoying parts.

Then there’s the second approval gate: “Publish it”.

I wanted that to be explicit. Not “looks good”, not “seems fine”, not something vague that could accidentally count as approval. If I haven’t said “Publish it”, it shouldn’t publish.

Once I do say it, Codsworth turns the post into the right Eleventy markdown, creates a branch, commits it, pushes it, and opens a PR. That PR kicks off a Netlify preview build, which means I can look at it on an actual preview of the site before anything gets merged.

That matters because it fits the workflow I already use. The blog already lives in Eleventy, markdown, GitHub and Netlify, so I didn’t want some weird parallel publishing system just because an AI is involved. The assistant fits into the existing workflow rather than replacing it.

It also means there are a few points where I can stop the process if something looks off. The outline can be wrong. The draft can be wrong. The formatting can be wrong. The preview can be wrong. Fine. That’s the whole reason for having approval gates in the first place.

Technically, it can also merge the PR, but only after explicit approval. And if it ever gets ideas above its station, that’s easy enough to fix by changing the token permissions. I’m not trying to build a system that’s trusted forever no matter what. I’m trying to build one that’s useful while it behaves itself.

That’s really the whole philosophy behind it: assisted, not automatic.

I’m not trying to build an autonomous publishing machine. I’m trying to build something that helps. Those are very different things.

A helpful assistant can organise a workflow, help shape an idea, draft something, and take care of the boring steps at the end. An “autonomous” system usually sounds impressive right up until it does something obviously stupid. I’d rather keep the human judgement in the loop and let the machine do the bits that are repetitive.

The funny thing is that even with all the limits, Codsworth can still do quite a lot, because at the end of the day it’s still basically a normal non-admin user on that machine. It can manage its own files, run tools, and generally get on with things inside that account. Which is exactly why I’ve kept that account signed into almost nothing. The best way to stop an agent from getting into things it shouldn’t is to make sure those things were never available to it in the first place.

There’s nothing especially fancy here, and that’s probably my favourite part of it.

It’s an always-on Mac Mini. A separate non-admin user. Almost no sign-ins. OpenAI for model access. A tightly scoped GitHub token for one repo. WhatsApp as the interface. Two explicit approval gates before anything gets published. That’s basically the whole setup.

I think there’s a temptation with this stuff to make it clever before you make it sensible. Or to make it sprawling before you make it useful. I’ve tried to do the opposite. Start with something small, understandable, and slightly boring. If it earns more responsibility later, fine. But it doesn’t get that by default.

At the moment, this feels about right. Useful enough to be worth having around, constrained enough that it doesn’t feel reckless, and simple enough that I can explain it without needing a diagram that makes me look like I’ve been pinning red string to the wall.

This will probably go wrong soon enough. I’ll report back.