Codex CLI 0.146.0 Moves the Agent Boundary Out of the Terminal
Codex CLI 0.146.0 gives agent builders a new place to draw the system boundary.
The easy summary is a list: Agent Plugins manifests, workspace publishing, remote Code Mode over WebSocket, custom-provider web search, executor-owned skills, and a long run of MCP and proxy fixes. That list is accurate. It also undersells the release.
Read together, these changes split a coding agent into replaceable planes. A plugin can carry a portable core. Codex can add its own policy and interface layer. The app server can send code execution to another host. A custom model provider can advertise a specific search capability. An executor can expose skills without turning its whole filesystem into ambient context. MCP connections can be reconciled while sessions stay alive.
This is how a terminal tool starts becoming an agent runtime.
The shift is meaningful precisely because it is incomplete. Agent Plugins 1.0 standardizes skills and MCP servers, not every hook, permission, app, subagent, or installation rule. Remote Code Mode moves an execution subsystem, not the entire agent session. OpenAI's Bedrock and Claude Code marketplace notes describe narrower routing and source-mapping changes than the word “marketplace” suggests.
The useful way to read OpenAI's stable July 29 release is therefore not “Codex supports everything everywhere.” It is this: Codex now has enough explicit seams to let packages, providers, executors, and network policy evolve independently—while keeping the host responsible for trust.
OpenAI published @openai/codex 0.146.0 as a stable release on July 29, 2026. The GitHub release points to commit e363b08, and the comparison against 0.145.0 is 222 commits ahead. That scale helps explain why the interesting parts are distributed across feature notes, bug fixes, protocol code, and merged pull requests.
Here is the fact layer before the interpretation.
| Shipped area | What 0.146.0 adds | The boundary it creates | What it does not prove |
|---|---|---|---|
| Agent Plugins | Parses the 1.0 manifest and maps portable skills plus MCP configuration | Portable package core versus Codex extension overlay | Universal hooks, permissions, UX, or marketplace compatibility |
| Workspace sharing | Exposes negotiated publishing capability metadata | Server-granted capability versus client assumption | Availability for every plan, role, workspace, or surface |
| Remote Code Mode | Connects app-server to a Code Mode host over WebSocket | Agent control plane versus code-execution plane | A durable remote session service or public-network security envelope |
| Provider web search | Lets compatible custom Responses providers opt into standalone search | Provider identity versus provider capability | Generic compatibility with arbitrary search APIs |
| Executor skills | Lists and reads bounded, executor-authority skill resources | Discoverable capability versus ambient filesystem access | Unbounded context or implicit trust in executor content |
| MCP and proxy lifecycle | Reconciles connections and broadens shared network routing | Replaceable capability transport versus persistent host policy | Automatic recovery from every auth failure or governance of all egress |
The release also adds named and pinned sessions, side-conversation switching, and paginated thread forks. Those are useful on their own. Architecturally, they point in the same direction: the session is becoming a managed object rather than a scrollback buffer attached to one terminal window.
Codex 0.146.0 does not collapse the stack into one standard. It makes the handoffs between layers more explicit.
The phrase “Agent Plugins support” invites a grand interpretation: package a workflow once, then run it unchanged in Codex, Claude Code, Cursor, AWS, and every future agent client.
The specification is more disciplined than that.
Agent Plugins 1.0 defines exactly two portable component types: Agent Skills under skills/, and MCP server configuration in mcp.json. A root plugin.json provides metadata and a versioned conformance point. Other components—including commands, hooks, agents, rules, and LSP servers—remain outside the portable v1 format because their host contracts have not converged.
Codex's manifest implementation follows that split. Portable fields enter through the shared schema. Codex-specific apps, hooks, and interface settings live under the extensions.com.openai namespace or a Codex overlay.
That is not a disappointing compromise. It is the architecture most agent ecosystems will probably adopt:
portable core
├── metadata
├── skills
└── MCP servers
host overlay
├── hooks and approvals
├── apps and interface settings
├── permissions and sandbox policy
├── installation and updates
└── marketplace and workspace controls
The portable layer answers, “What capability is in this package?” The host layer answers, “May it run here, with which identity, against which data, through which network path?”
This advances the argument from our earlier piece, OpenAI Skills Turns Agent Workflows Into a Cross-Product Standard. Skills make procedures portable. Agent Plugins turns those procedures into a package with discoverable metadata and MCP dependencies. The new engineering problem is no longer only authoring the workflow. It is preserving provenance while that package crosses hosts.
One caveat deserves a staging test. The tagged source contains the Agent Plugins parser, but some common discovery paths still visibly enumerate older .codex-plugin, .claude-plugin, and .cursor-plugin locations. That is not enough evidence to call the stable release broken. It is enough reason to test a package that contains only the root plugin.json before standardizing an internal publishing pipeline around it.
OpenAI's release note says 0.146.0 adds “additional plugin marketplaces for Amazon Bedrock and Claude Code.” The linked implementation is more specific.
For the resolved amazon-bedrock provider, Codex selects OpenAI's API-curated plugin catalog, including when Codex authentication is absent. This is provider-aware catalog routing. It is not an integration with AWS Marketplace.
For enabled claude-code-plugins entries whose source is missing, Codex infers the bundled anthropics/claude-code source while preserving a source that was explicitly discovered. This is identity repair and migration hygiene. It does not establish that Codex can consume every third-party Claude Code marketplace or reproduce Claude Code's richer native plugin surface.
That distinction matters for product promises. Marketplace interoperability has at least four layers:
Version 0.146.0 makes progress on the first two. Agent Plugins narrows the portable answer for the third. The fourth remains intentionally host-specific.
My expectation is that provider-aware routing expands faster than universal compatibility. Catalogs are useful even when packages need adapters. Rich hooks, subagents, LSP integrations, binaries, and permission systems are much harder to normalize without reducing them to the least capable host.
The most consequential runtime change is easy to overstate.
Codex app-server can now connect to a remote Code Mode host over ws:// or wss://. When the flag is omitted, it continues to start a local host. The app-server implementation shares one remote connection across process threads and uses the configured HTTP client's proxy and TLS policy. The underlying host transport keeps the existing framed protocol inside binary WebSocket messages.
This creates a useful deployment seam:
Codex session + approvals + tools
|
| bounded WebSocket protocol
v
separate code execution host
An organization can place execution nearer a controlled workspace, specialized compute, or a private network while keeping app-server elsewhere. Tool providers can treat the executor as a bounded authority that exposes skills and resources. Operators get a readiness endpoint and connection-level failure isolation.
But the host is not a complete remote agent service. It does not own the full session, conversation replay, identity lifecycle, multi-client state, or durable orchestration contract. That makes it narrower than the session protocol discussed in VS Code's Agent Host Protocol Turns Agent Sessions Into Infrastructure, and narrower than a managed runtime such as AWS AgentCore.
The maturity labels are also split. In the 0.146.0 feature registry, code_mode_host is stable and enabled by default, while the JavaScript code_mode feature remains under development and off by default. OpenAI can harden the execution topology before declaring the model-facing tool surface broadly stable.
The tagged protocol has concrete backpressure limits: JSON payloads up to 64 MiB, 256 host-global in-flight requests, 128 active cells, 1,024 unresolved delegate callbacks per connection, and a 128-frame outbound queue. Those numbers are not performance claims. They are the envelope a remote executor integration must observe and instrument.
That warning is not an argument against the feature. It clarifies what OpenAI shipped: a protocol boundary and transport, not a turnkey secure remote-execution product.
The least glamorous section of the changelog may be the most important for production.
Codex 0.146.0 reuses unchanged healthy MCP connections, replaces closed clients, prewarms changed runtime state, snapshots authentication, and reconnects configured servers on explicit refresh. The release notes group these fixes under keeping MCP connections and Apps tools current as authentication or configuration changes.
This lands immediately after the MCP ecosystem's move toward more self-contained, stateless HTTP requests, which we covered in MCP 2026-07-28 Deleted the Transport Session. Your Agent Still Needs One..
There is a useful systems lesson here: making the capability plane more replaceable does not remove state; it moves responsibility for state upward.
The transport may no longer own a sticky session, but Codex still needs to know:
The agent host becomes more stateful precisely because the capability endpoints are easier to replace. That is the same pattern visible in service meshes, database pools, and container schedulers: decoupling raises the value of reconciliation.
This is one of the release's non-obvious competitive signals. Model quality is visible in demos. Runtime reconciliation quality is visible only after a credential rotates during a long task, a server closes unexpectedly, or two threads observe different configuration. Builders notice it when the system stops feeling haunted.
OpenAI lists expanded proxy routing as bug fixes. For enterprise deployments, it is closer to a platform feature.
Version 0.146.0 brings authentication, remote plugin catalog and download flows, MCP authorization, remote execution, WebSockets, redirects, LM Studio, and other paths under more consistent configured proxy behavior. Redirect routing is recalculated across hops, with cross-origin credentials stripped in the linked implementation.
A federated agent cannot claim a coherent security boundary if every subsystem makes its own egress decision. Once packages can fetch capabilities, MCP can authorize remotely, an executor can live behind WebSocket, and model providers can vary, the proxy becomes part of the agent control plane.
The work is not necessarily complete. An open user report says browser-plugin or in-app-browser traffic can bypass configured proxy settings. One issue is not proof of universal behavior, but it is enough to avoid the phrase “all egress is governed.”
The right operational test is subsystem-by-subsystem:
model requests
plugin catalog and downloads
MCP OAuth and traffic
remote executor WebSocket
redirects
browser and in-app web traffic
local model providers
If one branch escapes policy, the runtime is only partially governed.
Three smaller changes reveal the same design principle.
First, workspace publication is exposed through nullable canPublishToWorkspace capability metadata in plugin-sharing contexts. The merged change tells clients to fail closed when the capability is unavailable. Publishing is an entitlement negotiated with the server, not a button inferred from a package's existence.
Second, custom Responses providers can advertise supports_standalone_web_search = true. The provider implementation defaults that capability to false and expects the provider's authentication plus a specific search path. “OpenAI-compatible” is no longer a sufficient compatibility claim; builders need a feature matrix and conformance tests.
Third, executor-owned skills arrive through skills.list and skills.read under executor authority. The skill-tool change adds pagination, package-relative resource containment, response limits, and stale-cursor checks. Explicit-only skills can remain absent from broad discovery while their selected resources are still readable.
Together, these changes replace ambient assumptions with declarations:
Can this workspace publish?
Can this provider search?
Which skills does this executor expose?
Which resource may this selected skill read?
That looks bureaucratic until an agent operates across multiple trust domains. Then it is the difference between composability and accidental authority.
Portability wins developer attention because it reduces duplicate packaging. Provenance will decide whether enterprises trust the result.
A portable plugin can still start a local MCP process. A skill can still contain scripts. A Codex overlay can still add hooks. The Agent Plugins specification contains paths within the package, but it does not sandbox plugin subprocesses or standardize host permissions. OpenAI's plugin documentation separately requires users to review and trust hooks before Codex runs them.
So the durable deployment record should include more than plugin.json:
publisher identity
marketplace source
manifest schema version
resolved package revision
skill and resource hashes
MCP endpoints and transports
host-specific hooks
requested permissions
user or admin approvals
commands actually executed
This is where 0.146.0 connects to OpenAI's Codex Security CLI Makes Missing Evidence Fail the Build. Cross-client packaging is valuable only if the evidence chain survives the move. Otherwise, portability becomes a reproducibility regression: the same friendly plugin name can resolve to different code, policy, or authority on two hosts.
Stage it now if you operate MCP-heavy Codex environments, build plugin catalogs, maintain custom Responses providers, or need to separate app-server from code execution. The release addresses boundaries you already own.
Pilot plugin publishing, proxy behavior, auth refresh, and remote execution inside a controlled workspace. The architecture is valuable, but availability and policy behavior can vary by surface and workspace.
Do not upgrade expecting smarter code, lower cost, or faster completion. OpenAI published no 0.146.0 benchmark, pricing change, throughput result, or SLA improvement.
Treat this as an infrastructure upgrade, even if installation is one npm command.
There are two failure modes worth resisting.
The first is testing only the happy-path command. Most value in this release appears after state changes: credentials rotate, a remote host reconnects, a plugin crosses a workspace boundary, or an executor advertises a resource the main host did not already know.
The second is treating every release-note noun as a general-availability promise. Workspace publishing is negotiated. Standalone provider search is opt-in and under development. JavaScript Code Mode is under development even though the remote-host transport is stable. Claude Code marketplace source inference is not arbitrary marketplace execution.
Exact language makes better systems.
Three consequences look likely.
Skills and MCP have enough cross-client agreement to travel. Hooks, agents, rules, interfaces, binaries, and permissions do not. Vendors will compete on those overlays while converging on a smaller inspectable core.
That is healthier than forcing premature standardization. It lets the common layer earn stability from actual interoperability rather than committee ambition.
OpenAI now has the topology for app-server to reach a separate executor through wss://, configured TLS, and proxy policy. The bundled host side still needs a clearer authenticated deployment contract before teams should treat it as an internet-facing service.
I expect first-class secure-host guidance, identity, or a managed remote executor layer to follow. The transport is useful now; the product envelope is unfinished.
Custom providers already need to advertise standalone search. Workspaces advertise publishing. Executors advertise skills and bounded resources. This pattern will spread to code execution, browser control, memory, media, and other agent tools.
The label “compatible provider” will lose meaning without a machine-testable capability profile. The next generation of agent integrations will look less like a single API clone and more like protocol negotiation.
No. OpenAI announced no release-specific model benchmark, price, usage limit, throughput figure, or SLA change. This release changes the CLI, app-server, plugin, executor, MCP, provider, and network-policy layers.
No. It standardizes a root manifest, Agent Skills, and MCP server configuration. Host-specific hooks, apps, agents, rules, interfaces, permissions, installation, and UX can still differ. Think portable core, vendor overlay.
The evidence does not support that broad claim. The Bedrock change selects an OpenAI-curated catalog for the resolved provider. The Claude Code change infers a bundled marketplace source when attribution is missing. Test the exact catalog and component set you plan to support.
No. It moves the Code Mode execution host behind a WebSocket connection. App-server still owns broader agent and session behavior. The transport does not by itself provide durable sessions, multi-client replay, or a complete public-network security layer.
codex-code-mode-host to the public internet?Not directly. The tagged host listener accepts plain ws:// and does not show a complete listener-side authentication and TLS envelope. Use loopback or private networking, or an authenticated TLS-terminating proxy, and validate the deployment against your own threat model.
Run a staged integration test around the boundaries that changed: bare Agent Plugins discovery, workspace publication capability, MCP auth rotation, proxy routing, remote-executor reconnects and limits, custom-provider search negotiation, and executor resource containment.
Codex CLI 0.146.0 is important because it makes the agent stack less implicit.
Packages get a portable core. Codex keeps a policy overlay. The executor can move behind a protocol boundary. Providers declare capabilities. Workspaces grant publication rather than letting clients assume it. MCP connections are reconciled while sessions continue. Network policy begins to span the parts.
None of those changes completes the universal agent runtime. Together, they show what one will require.
The terminal remains the interface many developers see. Underneath it, Codex is becoming a control plane for packages, sessions, providers, tools, executors, and trust decisions that no longer need to live in one process or one machine.
That is the boundary 0.146.0 moved.