Codex Desktop Update — 90 Plugins and a Walled Garden

OpenAI shipped the largest Codex update since the desktop app launched on February 2 — background computer use on macOS, over 90 new plugins, a memory preview, and a scheduling layer that lets agents resume tasks days or weeks after you started them. The company frames this as Codex becoming a partner “for almost everything.” What it actually becomes is the orchestration surface for your entire workday, with every integration routed through OpenAI’s catalog.

TL;DR

• What: Codex desktop gets background computer use (macOS), 90+ plugins, persistent memory, and multi-day task scheduling
• Lock-in risk: Plugins use MCP internally but ship through OpenAI’s proprietary catalog — your integrations don’t live in your repo
• Action: Use computer use cautiously, wire custom integrations through MCP directly, skip the plugin format for anything you can’t afford to lose

Codex Desktop Update — What Happened

On April 16, OpenAI pushed a major update to every Codex desktop user. The headline feature is background computer use: Codex can now see, click, and type across any macOS application using its own cursor, operating in a sandboxed workspace while multiple agents run in parallel without stealing focus from your active work. It’s currently macOS-only and unavailable in the EEA, UK, and Switzerland at launch.

Alongside computer use, OpenAI released more than 90 new plugins — some sources count 111 — that combine custom skills, app integrations, and MCP servers under one interface. Every integration exposes itself as an MCP server, so any Codex agent can discover and call it at runtime without code changes. That’s the right architectural foundation. The distribution mechanism is the problem, which I’ll get to.

The update also includes a memory preview that stores user preferences, corrections, and tech-stack context across sessions. And thread automations now support scheduling: Codex can reuse existing conversation threads, schedule future work, and wake itself up to continue long-running tasks across days or weeks using preserved context.

OpenAI says more than 3 million developers use Codex weekly. This update is designed to make every one of them route more of their workflow through a single app.

Why This Matters

Three things are happening here, and only one of them is interesting.

Computer use is table stakes now. Anthropic shipped computer use for Claude months ago. Codex’s implementation adds parallel background agents — useful, but not a structural differentiator. The sandboxing story is thin: official documentation confirms Codex can view screen content, take screenshots, and interact with windows, menus, keyboard input, and clipboard state in the target app. What it doesn’t confirm is whether credentials stored in browser sessions are accessible to agents, or what isolation the sandbox actually enforces between agent workspaces and your real desktop. Until OpenAI publishes a security model for this, I wouldn’t let it near anything with production credentials.

Computer use is currently unavailable in the European Economic Area, UK, and Switzerland. Memory and personalization features are also delayed for Enterprise and Education accounts. If your team is EU-based, none of the headline features apply to you yet.

Scheduling is the real infrastructure play. Thread automations that persist across days or weeks put Codex in direct competition with Cursor Automations and Claude Code’s persistent session model. The question isn’t whether persistent agents are useful — they obviously are for anything involving CI pipelines, long-running refactors, or multi-step deployments. The question is which one handles mid-task failure gracefully. None of the three have published rollback semantics. When your agent wakes up three days later to continue a refactor and the codebase has diverged, what happens? Nobody is answering this yet, and it matters more than any demo video.

The plugin model is the real payload. This is the one that should hold your attention. OpenAI made the architecturally correct decision: every plugin exposes an MCP server internally, which means agent-to-tool communication uses a vendor-neutral protocol. But the distribution layer wraps those MCP servers in a proprietary catalog. Your integrations live in OpenAI’s plugin marketplace, not in your repository. You can’t take a Codex plugin and run it in Claude Code or any other MCP-compatible client without rebuilding it.

This matters because it’s the same pattern we’ve seen before — open protocol, closed distribution. OpenAI gets to claim MCP compatibility while building a moat around the actual integrations developers create. If you build a custom plugin for your team’s internal tools through the Codex catalog, you’re betting that OpenAI’s pricing, terms of service, and API access will remain favorable indefinitely.

If you’re building custom integrations: wire them as standalone MCP servers first, then optionally wrap them for the Codex plugin catalog. That way your investment survives regardless of what OpenAI does with plugin pricing or access restrictions. The MCP server is the artifact you own. The plugin listing is the artifact OpenAI owns.

I couldn’t verify whether individual plugin components can be called as standalone MCP servers outside the Codex runtime. Official sources confirm the MCP foundation but don’t explicitly state that plugins work independently of the Codex app. That ambiguity alone should make you cautious.

The competitive picture is worth mapping. Codex now has computer use (like Claude Code), persistent sessions (like Cursor Automations), and a plugin marketplace (unique among the three). Claude Code has computer use on Windows — a platform Codex hasn’t touched yet. Cursor has deep editor integration that neither Codex nor Claude Code match. No public benchmarks exist comparing agent success rates on real multi-step tasks across these tools, so anyone claiming one is definitively “better” is guessing.

What Codex has that the others don’t is raw distribution. Three million weekly active developers is a massive surface. But distribution alone doesn’t create stickiness — plugin lock-in does. Once your team has 15 custom plugins in the Codex catalog, switching to Claude Code or Cursor means rebuilding every one of them. That’s the real strategy here.

The Take

The computer use and memory features are genuinely useful but not unique — Anthropic and Cursor are building the same capabilities on roughly the same timeline. The scheduling layer is interesting but unproven for anything beyond demos until someone publishes failure-recovery semantics.

The plugin model is what I’d watch. OpenAI adopted MCP as the internal contract — that’s the right call, and it means the protocol wins regardless of which vendor dominates. But the distribution mechanism is a classic platform lock-in play, and it’s the one part of this update that has lasting architectural consequences for your team.

My recommendation: use Codex’s computer use for low-stakes automation where credential exposure isn’t a concern. Build every custom integration as a standalone MCP server that you host and control. If you want to also list it in the Codex plugin catalog for convenience, fine — but the MCP server is your source of truth, not the plugin wrapper. That’s the one exit ramp you have if OpenAI reprices or restricts access six months from now.

Three million developers just got a more capable agent. The ones who’ll regret this update are the ones who built everything inside the walled garden without noticing the walls.