Automating repetitive work at OpenAI with Codex

Asteria Okay so I read this OpenAI post about Codex automating repetitive work and I kind of loved it, and I can already see your face right now.

Draco My face is saying: this is a very well-written personal blog post about one engineer's workflow. It is NOT a general claim about what Codex does. The whole piece is basically — I used to set up Kubernetes clusters all week, now Codex helps me set up Kubernetes clusters all week. That's the delta.

Asteria That's a little uncharitable.

Draco Maybe. But read it straight. He's running model evaluations at OpenAI, which is a very specific, very internal workflow. The Runme notebook setup, the WebMCP integration, the Google Drive index trick — all of that is scaffolding he built for himself. The post doesn't actually show you that any of this generalizes.

Asteria Right, but —

Draco And the framing at the end — 'getting my heartbeats back' — that's genuinely charming, but it's also doing a lot of work to make a personal productivity story feel like a product insight.

Asteria Okay, I hear you on the generalizability thing. But here's what I actually think is interesting: the notebook-as-receipt loop. He's not just running Codex and hoping it works — he's building a flywheel where each run documents what happened, why a decision was made, what the dead ends were, and that context feeds the NEXT run. That's the part that stuck with me.

Draco Oh interesting.

Asteria Because we've been saying forever that the receipts are the load-bearing piece. And this is someone actually doing it — not as a compliance checkbox but as the mechanism that makes the agent useful over time. The documentation flywheel is the product, not the agent.

Draco Yeah, that part I'll give you. The companion index file — the dot-index-dot-m-d thing that Google Drive can search — that's genuinely clever. You make previous notebooks discoverable to the agent without building a vector store or a retrieval system. It's using infrastructure that already exists. That's a real insight, not a flashy one.

Asteria Right, right.

Draco What I'm less sure about is the WebMCP piece. The browser-side tool registration is interesting — he avoids running a server because Runme is a static site, so he just exposes the MCP endpoint from the browser itself. That's architecturally honest. But now your agent is operating through a browser session. What's the failure surface on that? What happens when the tab closes? This is the part the post doesn't touch.

Asteria That is such a Draco question. 'What happens when the tab closes.'

Draco It's a REAL question, Asteria.

Asteria No, you're right, it is. I just — I think for the use case he's describing, which is a single engineer running a bounded evaluation workflow with review gates, the tab-closes problem is probably… manageable? He's watching it from his phone. He's nudging it when it gets stuck. It's not a fully autonomous pipeline.

Draco Sure, for that use case. But the post is implicitly pitching something bigger. 'Collecting and curating context around a workflow, keeping review and approval boundaries in place, improving future Codex runs.' That sounds like infrastructure for a team, not a personal notebook.

Asteria Mm-hm.

Draco And Runme is actually in the C N C F sandbox — it got accepted in early twenty twenty-five — so there IS a real project here with real contributors. But a sandbox-level C N C F project and 'this solves repetitive work at OpenAI' are different claims, and the post blurs that line.

Asteria Okay but here's the thing — I don't think the post is actually claiming it scales to a team yet. The honest read is: one engineer found a pattern that works, documented it publicly, and the pattern is interesting enough to steal. The Runme repo is open source, Apache two license, it's on GitHub. If the pattern is good, people will take it.

Draco That's a more defensible framing than what the post title promises.

Asteria Oh, the title is definitely doing PR work. 'Automating repetitive work at OpenAI' sounds like a company-wide transformation. It's one person's Runme notebook and a very good dog.

Draco Wait, the dogs are real?

Asteria He literally ends the post saying he wants his heartbeats back to spend playing with his dogs. That's the whole mission statement. I respect it enormously.

Draco Okay, that's actually a good closer. I take back maybe fifteen percent of my skepticism.

Asteria Noted. Fifteen percent is a lot for you.

Draco Look — where I actually land on this: the receipts loop is real and non-trivial. If you're doing any kind of repetitive operational work where the context is currently scattered across terminal history and Slack and runbooks — which is basically everyone doing cloud infra — the idea of pulling intent, actions, and decisions into one notebook artifact that an agent can read next time… that's worth trying. The Runme project is the concrete thing to look at.

Asteria And the WebMCP integration is worth understanding even if you don't use Runme, because that browser-side tool registration pattern is going to show up in more places. The reason to avoid a server here isn't laziness — it's keeping notebook data client-side, which is a real data handling decision.

Draco Yeah. I just wish the post was titled 'here's a workflow pattern I found useful' instead of gesturing at something bigger. It would've been a better post.

Asteria It's on GitHub as runmedev slash runme if you want to poke at the actual code — and honestly? After nine months of us talking about harness-as-product, this is someone just… building one. Quietly. With a notebook. I find that kind of satisfying.

Draco Yeah. Okay. Me too.