OpenAI moves the agent execution harness into the Responses API

The harness stops living on the client

The core structural change here is where the execution loop runs. OpenAI notes that when the Responses API is used with custom tools, it "yields control back to the client, and the client requires its own harness for running the tools." With the shell tool and hosted container, that harness moves server-side.

The described loop is concrete: the model proposes one or more shell commands, the API forwards them to a container runtime, streams output back, and re-injects that output into the next request's context. This repeats until the model returns a completion with no further commands. Nothing in that loop requires the developer to run a container, poll for output, or wire retries.

For frontend and client teams, this reframes what a request is. A single prompt can, per the post, "expand into an end-to-end workflow"—discovering a skill, fetching data, transforming it into SQLite, querying it, and producing an artifact—without the client owning any of the intermediate state.

How the loop stays fast and bounded

Two details keep the loop from stalling or flooding context. First, the model can propose multiple shell commands in one step, and the API executes them concurrently in separate container sessions, multiplexing the independent output streams back as structured tool outputs. The example given: searching files, fetching data, and validating intermediate results in parallel.

Second, the model sets an output cap per command. The API enforces it and returns a bounded result that preserves the beginning and end while marking omitted content—the post shows a 1,000-character cap with a "1000 chars truncated" marker in the middle. This is a deliberate answer to the anti-pattern of large tables and terminal logs eating the context budget.

The shell tool itself is broader than the existing Python-only code interpreter. It ships with grep, curl, and awk out of the box, and the post says it can run Go or Java programs or start a NodeJS server—so the execution surface is a Unix command line, not a single language runtime.

Compaction, and the Codex feedback loop that built it

Long-running tasks fill the context window, so OpenAI added native compaction. Trained models produce a "compaction item" that preserves prior state in an encrypted, token-efficient representation; the next window carries that item plus high-value portions of the earlier one. It's available as server-side automatic compaction with a configurable threshold or via a standalone /compact endpoint, and the server-side version tolerates small overages rather than rejecting requests near the limit.

The most specific claim in the post is how the system was built. Codex both built the compaction mechanism and served as its early user:

When one Codex instance hit a compaction error, we'd spin up a second instance to investigate. The result was that Codex got a native, effective compaction system just by working on the problem.Montana Labs

OpenAI frames this as Codex learning alongside its engineers. It's also a signal about how these primitives are validated internally before shipping—the compaction path is the same one Codex depends on to sustain long coding sessions.

The security model developers inherit instead of reinvent

Container network access is handled through a sidecar egress proxy: all outbound requests flow through a centralized policy layer that enforces allowlists while keeping traffic observable. Credentials use domain-scoped secret injection at egress—the model and container see only placeholders, and raw secret values stay outside model-visible context, applied only for approved destinations.

This is the part client teams most often get wrong when building their own agent sandbox. By moving credential handling and network policy to the platform, OpenAI is claiming ownership of the leakage and exfiltration surface that would otherwise sit in each developer's infrastructure.

What a client-side developer now owns—and doesn't

The specific implication of this announcement is a narrowing of the client's job. Orchestration, sandboxed execution, output truncation, context compaction, network policy, and secret scoping are now platform primitives. Skills—versioned folder bundles with a SKILL.md—let teams package repeated multi-step patterns as reusable logic the model discovers with plain shell commands like ls and cat.

What remains on the developer side is design work: staging inputs in the container filesystem rather than the prompt, describing SQLite tables so the model queries only relevant rows, and authoring skills that encode conventions. The tradeoff is clear—less infrastructure to run, but a heavier dependency on OpenAI's runtime and its GPT-5.2-and-later models, which are the only ones trained to propose shell commands. Teams that already built robust harnesses should weigh what they give up in portability against what they stop maintaining.