$ Codex Is Becoming an Operating System for Agents

It feels appropriate to be working through this article in a conversation with GPT. This is how I begin most work now: I describe what I’m trying to achieve, explain the context, and start working with an agent on how to get there.

But the more I work this way, the more I realize that the model is only part of the story.

The environment around it matters at least as much. How do I give it context? How does it interact with my tools? Can it delegate? Can I steer it without restarting the work? Can it coordinate with something that is already running somewhere else?

Those questions are why I think Codex deserves a different conversation from the one we usually have about coding assistants.

In my workflow, Codex has become something of an operating system for agents.

I’m not suggesting it replaces macOS, Windows, or Linux. I’m describing the role it plays for me: the place where I bring together context, tools, sessions, and other agents to pursue an outcome.

Just by asking, I can spin up a new project and start working across my entire computer: apps, connectors, MCP integrations, and even other coding agents.

And I’m specifically talking about Codex on my local machine. That distinction matters. A local Codex workspace, with its configured tools and permissions, is not interchangeable with a web chat.

The important shift is where the work happens

When I use the word harness, I mean the system around the model that makes useful work possible: its instructions, context, tools, permissions, execution environment, and feedback mechanisms. I made the longer case in Harness-Driven Development: you are not using a model, you are using a harness, and the same model in a different harness is a different engineer. Harnesses are not interchangeable. As I put it in The Magic Prompt, Codex has one set of capabilities and Claude Code exposes another, and any serious workflow has to know which one it is running in.

The model matters. A lot. But I don’t experience Codex as a model sitting behind a text box. I experience it as an environment in which I can establish a goal and begin working toward it.

That might involve a repository, but it doesn’t have to stop at the repository.

Codex can connect to external tools and context through MCP servers, and the desktop app, the CLI, and the IDE extension share that configuration on the same machine. With the right setup and permissions, the desktop app can also see and operate graphical applications on macOS and Windows when a command-line tool or a structured integration is not enough. These are different routes into the environment where the work actually happens.

For me, the significance is not simply that there are more integrations.

It is that I spend less time acting as the integration.

I don’t want to copy an explanation from one window into another, reconstruct the project’s history for another agent, collect its response, and manually carry that response back. Sometimes that is necessary. But it shouldn’t be the default architecture of working with agents.

I want to explain the outcome, establish the boundaries, and have a capable coordinating agent work through the available interfaces.

This is also why interoperability needs to work in both directions. Codex should be able to use other tools, but other tools and external harnesses should also be able to use Codex.

There is a concrete foundation for that. Codex’s App Server exposes a JSON-RPC interface for thread management, approvals, and streamed agent events: create, resume, fork, or branch a thread, and steer or interrupt the turn running inside it. It exists so that rich clients and third-party integrations can drive Codex. Codex is not accessible only through a window that a human must operate.

That is where the operating-system analogy starts to make sense to me. An operating system doesn’t need to be every application. Part of its value is letting different programs do useful work together. It is the same instinct behind Skills, Pipes, and the Unix Philosophy: small pieces with well-defined interfaces compose, and one large piece that tries to be everything does not.

Likewise, Codex doesn’t need to be my entire agent setup to become its centerpiece.

A session becomes more than a conversation

The capability I lean on most in my local setup is working across sessions.

One chat can look into another: read its transcript as a native tool, send a message to a session that is already running, pick up its work, or start a new project from it. Instead of treating every conversation as an isolated exchange, I can treat sessions as parts of one working environment.

That doesn’t mean every chat automatically knows everything in every other chat. There is an important difference between information existing somewhere and the current agent having access to it through an available interface.

What matters to me is that I don’t always have to be the person transporting that information.

Once a session has accumulated the intent behind a project, it becomes valuable in a way that a fresh prompt is not. It contains the questions we considered, the constraints we established, the approaches we rejected, and the reasons behind those decisions.

I want to be able to return to that working relationship. I also want other work to benefit from it without forcing everything into one enormous conversation.

This changes what I ask of a chat interface. I’m no longer looking only for somewhere to enter a prompt. I’m looking for somewhere to organize and steer ongoing work.

Voice makes this especially interesting.

The desktop app’s voice mode is more than dictation. It can start separate tasks, check on existing ones, report progress, and take an interruption mid-task when I want to change direction. Availability depends on your plan, rollout, and workspace settings, so you may not have it yet.

The interaction I care about sounds something like this:

Check where that investigation stands and tell me what is blocking it. Keep the implementation moving, but don’t change the approach until we’ve reviewed the alternative.

That is a different relationship with a computer from opening applications one by one and performing each step myself.

I think voice conversation is the next way people will talk to their harnesses. Not because typing will disappear, or because every task benefits from being spoken aloud, but because expressing intent and reviewing decisions are conversational activities.

The important part is continuity: being able to change how I communicate without having to restart the work.

Long-running work changes what I delegate

There is a difference between asking an agent to perform a step and asking it to pursue a goal.

A step sounds like this:

Inspect this function.

A goal sounds like this:

Work out why this behavior is failing, look at the relevant parts of the system, propose a fix, implement it within the boundaries we agreed, and verify the result.

The second requires more than a good first response. It requires maintaining direction as new information appears.

This is one of the reasons Codex has become central to my workflow. I give it work that has a trajectory, not a sequence of disconnected prompts.

Goal mode makes that distinction explicit. A goal needs an outcome, constraints, and verification criteria, and once it is running I can pause it, resume it, edit it, or steer it with a follow-up message.

But I don’t use durable to mean an immortal process or perfect memory. I mean work that I can return to, understand, and continue without reconstructing the entire purpose from scratch. Local execution still needs an available environment; persistence of a session is not the same thing as uninterrupted execution.

For a centerpiece harness, the questions I care about are practical.

Does it still understand what we are trying to achieve? Can I tell what has changed? Can I interrupt an assumption without throwing away the larger goal? Does it know what evidence would justify calling the task complete?

A task running for a long time is not impressive by itself. What matters is whether that time is producing justified progress toward the intended outcome. That is the same architecture of verification I wanted from agents before any of this existed: plan, execute, verify, iterate, and never mistake a confident completion message for evidence.

This also changes my responsibility as the operator. I need to be clearer about what “done” means, which decisions I’m delegating, and where the agent needs to stop and involve me.

Side chats let me keep thinking while work continues

Once a main session has developed substantial context, I don’t want to abandon it every time another question comes to mind.

But I also don’t want every question to interrupt its work.

Maybe I want to understand a decision. Maybe I want to explore an alternative. Maybe I want to challenge an assumption before deciding whether the main task should change direction.

This is why I find side chats so useful. The documented workflow is exactly that: open a side chat for an explanation or a status recap without interrupting the main chat, in its own context, so two chats never edit the same files at once.

In practice, I use that space to keep thinking around the work while the main thread continues.

The main session can remain the center of the project’s execution, while I investigate something adjacent to it. I don’t need to choose immediately between derailing the current task and opening a completely disconnected conversation.

There is one limitation I keep running into in my current setup: side chats don’t launch subagents.

Some people will reasonably say that this is not critical. And for a quick explanation, it is not.

But sometimes a side question is not a small question.

Is this really the right approach?

Answering that might mean exploring the codebase, checking a dependency, and challenging the assumptions behind the current plan.

At that point, I would like the side investigation to benefit from the same delegation capabilities as the main session.

That distinction is important: I use side chats to continue my own investigation alongside the work; I use subagents to delegate pieces of the work itself.

They solve related, but different, problems.

The power of subagents is not just parallel execution

People like the idea of a magic word. With Codex, one comes surprisingly close:

Use a subagent for this.

There is nothing mystical about it. It is an instruction to use a delegation capability the subagent documentation describes plainly: ask for subagents or parallel agent work directly, and each one runs in its own thread and comes back with a focused summary. In most configurations you do have to ask; it won’t usually delegate on its own. And in my experience I haven’t needed to define a custom agent role before asking.

What I find powerful is how little ceremony I need before trying it.

I don’t necessarily need to stop working, design a permanent agent role, create another process, and manually manage the exchange. I can ask for a specialist suited to the problem in front of me.

But there is a less obvious point here.

Figuring out what to delegate is often harder than spawning the agent.

Suppose I am evaluating whether to add a dependency to a project. What specialist do I actually need?

A generic “research agent” might return a feature comparison. That could be useful, but it might completely miss the decision I need to make.

Perhaps I first need an explorer to establish how the project currently handles the relevant behavior. Then I need someone to look for evidence that the proposed dependency solves a real gap. Perhaps I need an adversarial reviewer whose job is to find a simpler approach.

Those are different assignments, with different evidence requirements.

A request could look like this:

Before proposing this dependency, use one subagent to inspect how the project handles the requirement today, and another to investigate whether a simpler approach would satisfy it. Keep both investigations read-only. Ask them to return evidence, uncertainties, and the assumptions their conclusions depend on. Compare their findings before recommending a change.

The important part is not the number of agents. It is the division of responsibility.

On another task I might need a fixer working against a narrowly defined failure, then a reviewer checking whether the fix actually addresses it. I might need an LLM as a judge against explicit acceptance criteria, an adversary whose only job is to give me the feedback I don’t want, or a scout whose only responsibility is to find out what we don’t yet understand.

I don’t want to assume that one predefined collection of roles is appropriate for every problem.

What I want is to work with the main agent to discover the right delegation structure for the task we are doing now.

This is where separate working contexts earn their keep. An exploration produces a lot of intermediate material that doesn’t belong in the main conversation. Because each subagent runs in its own thread and returns a summary, the investigation moves out of the main session, and the main session stays oriented around requirements and decisions.

However, I would not treat two agents agreeing as proof of correctness. They may be working from the same mistaken assumption. A judge still needs meaningful criteria. A reviewer still needs evidence. A fixer still needs verification.

And more agents are not automatically better. The same documentation is candid about the cost: subagent workflows consume more tokens than a comparable single-agent run, and several agents editing code at once can create conflicts. Coordination is never free.

The real advantage is being able to experiment with delegation without first building an orchestration system for every idea.

Being the centerpiece does not mean replacing everything else

I haven’t moved everything into Codex. In Buzzcut I described my split: Claude Code for most serious repository work, Codex for a second opinion with a different set of habits, and Grok Bot for small, sharply scoped bots that live close to a conversation rather than close to a codebase. Since then, more of that work has shifted toward Codex, and Claude Code is still very good at certain tasks. What this post adds is a different axis: not which agent writes the code, but which environment holds the goal.

Grok Bot is also where I go when I’m thinking about a persistent collection of bots with different responsibilities. That organizational question deserves its own article: how should an AI crew be structured, which responsibilities should remain durable, and which should be created temporarily for a specific task?

I’ve been experimenting with durable Codex sessions as personas, too. It’s fun. It works. But the ergonomics are nowhere near what Grok Bot gives me for that style of organization.

That doesn’t weaken my argument about Codex.

The place where I prefer to organize persistent personas doesn’t have to be the same place where I coordinate local execution. And the agent I prefer for a specific implementation task doesn’t have to own the entire workflow.

I’m more interested in how well these pieces cooperate than in finding one product that replaces all the others.

In my setup, Codex’s value is partly that it stays useful even when something else is doing part of the work. Its role can be to hold the broader goal, coordinate the interfaces, and help me evaluate what comes back.

That is a much stronger position than simply being another isolated assistant.

The boundaries are part of the design

There are limits, and they are worth stating without losing sight of what already works.

The one hard wall I have hit is computer use of Codex over Codex: asking Codex to drive its own app through the screen. The documented boundaries rule that out on purpose. Computer use will not automate terminal applications or the ChatGPT app itself, because automating them could bypass its security policies.

I don’t see self-operation through the screen as a prerequisite for the coordination I want. The session interfaces are a more direct way to work with existing tasks, within the permissions they expose.

More broadly, I don’t want a central harness whose usefulness depends on ignoring boundaries.

The more responsibility I give it, the more I care about being able to understand what it is doing, constrain its access, inspect its outputs, and intervene.

Likewise, I don’t want important project decisions to exist only somewhere in a long transcript. My expectation is that durable work produces durable artifacts: code, tests, recorded decisions, and enough evidence for someone to understand the result.

The conversation should help operate the project. It should not become the only place where the project exists.

Try Codex as a harness, not only as a code generator

The progression through GPT-5.5 and GPT-5.6 to GPT-6 Astra has changed what I’m willing to delegate. Things are on a different level from where they were a year ago. Astra is available in Codex, and OpenAI calls it its best model for software engineering to date.

So I implore you to try Codex. Not by asking the newest model to write a function.

Give it a real, bounded piece of work. Let it establish context in a project. Ask it to investigate before implementing. Open a side chat while the main task is running. Ask for a subagent where a separate investigation would help. Connect the tools the work actually needs, with the permissions it actually needs.

Then look at how the workflow changes.

How often are you reconstructing context? How much information are you carrying between tools? Can you continue thinking while execution is underway? Can you redirect the work without starting over? Are you getting evidence you can review, rather than only a convincing completion message?

Those are the questions that explain why I rely so heavily on Codex today.

I still open it to write code. But more and more, I open it because I have something I want to accomplish on my computer, and I want a capable agent to coordinate everything required to get there.

That is why “coding assistant” no longer feels like a complete description.

For me, Codex is becoming the operating environment in which agents do the work — not just another agent doing one part of it.

---

Dictated by voice, drafted in a conversation with GPT, then edited and published with Claude Code. The arguments are mine; the drafting was collaborative.