Codex Grows Up: From Code Model to Full Desktop Environment
OpenAI just updated the Codex app for macOS and Windows with a set of features that, taken together, signal a deliberate repositioning: computer use, in-app browsing, image generation, memory, and a plugin system. Each of these could be its own product announcement. Bundled into a single desktop app, they represent a different theory of what a developer AI tool should be.
The question worth sitting with is not whether these features are useful in isolation. They clearly are. The more interesting question is what it means when your AI coding assistant stops being a tool you reach for and starts being the environment you work inside.
A Brief History of What Codex Actually Is
It helps to trace what OpenAI has done with the Codex name, because it has meant different things at different times.
The original Codex model, launched in 2021, was a GPT-3 derivative fine-tuned on public code from GitHub. It powered the first version of GitHub Copilot and was accessible via API for developers building code-completion tools. OpenAI eventually deprecated the Codex API in March 2023, folding its capabilities into the GPT-3.5 and GPT-4 model families.
The name resurfaced with Codex CLI, a terminal-based coding agent released in early 2025. Codex CLI was a different kind of thing: not a model endpoint but an agentic loop running in your terminal, capable of reading files, executing shell commands, and making multi-step edits to a codebase. It was lightweight, composable, and designed to fit into existing developer workflows. You could run it alongside your editor, your test runner, your version control tooling. It did not try to replace any of those things.
The current Codex app is the third iteration, and it is considerably more ambitious than either predecessor.
Computer Use: The Hardest Feature to Get Right
Computer use is the most technically interesting addition, and also the one that carries the most risk if implemented carelessly.
Anthropomorphic descriptions aside, computer use in the context of AI tools means a model that can observe a screenshot of your screen, determine what to click or type, and issue those inputs to the operating system. Anthropic released their Computer Use API in October 2024, and the pattern has since spread across the major AI labs. The core loop is: capture a screenshot, pass it to the model along with a task description, receive a structured action (click at coordinates, type text, press key), execute it, capture the next screenshot, repeat.
The difficulty is not the mechanics. The difficulty is reliability. Computer use agents fail in ways that are hard to predict and sometimes hard to recover from. They misidentify UI elements, get stuck in retry loops, and occasionally take destructive actions because the model misread the state of the screen. Restricting the scope, running actions inside sandboxed VMs, requiring explicit confirmation for high-stakes operations: these are the engineering decisions that separate a demo from a tool you would trust in a real workflow.
OpenAI has not published detailed documentation on how the Codex app implements computer use at the system level, but given the context of a developer-focused product, the most likely use cases are things like navigating a browser to pull up documentation, clicking through a UI to test behavior, or operating GUI applications that have no API. Used that way, the blast radius of a mistake is limited.
In-App Browsing and the Context Problem
The in-app browser is, in some ways, a simpler feature with a large practical impact.
One of the chronic friction points in AI-assisted development is context retrieval. You are in the middle of a problem, you need to check a library’s changelog, read a stack trace on a forum, or pull up a spec. Every context switch to a browser is a small interruption. Over a day of work, they accumulate.
An integrated browser that the AI can also read and act on changes this dynamic. Instead of copy-pasting between tabs, the model can navigate to the relevant documentation itself, extract the information it needs, and apply it directly to the code under edit. This is not a new idea conceptually: Cursor and similar tools have had some version of context-from-URL for a while. But embedding a full browser with the model as a co-pilot is a more complete version of it.
The architectural question is how browsing context integrates with the model’s working context window. If the model can browse freely, every page it visits is potential noise as well as potential signal. Some form of selective attention, where the model decides what from a page is worth retaining and what to discard, is necessary to keep the context from filling up with irrelevant content.
Memory Across Sessions
OpenAI has had memory in ChatGPT since early 2024, and bringing a version of it to a developer tool is a natural extension. The core mechanic is that the model can write facts to a persistent store and retrieve them in future sessions. In a consumer product, this means remembering preferences, names, ongoing projects. In a developer tool, it means something more structured: preferred libraries, project-specific conventions, recurring patterns in how you like code organized, previous decisions about architecture.
This is not the same as loading your entire project into context every time. Memory, as implemented in these tools, is more like a curated set of notes the model maintains about you and your work. The quality of those notes depends on the model making good decisions about what is worth retaining, which is not trivial.
For tools like Cursor that already embed a representation of your codebase via embeddings and vector search, persistent memory is a complement rather than a replacement. You index the code for structural retrieval; you use memory for behavioral and preference continuity. The two systems serve different parts of the problem.
Plugins and the Extensibility Question
The plugin system is where this starts to look like a platform play.
Lookback at what happened with ChatGPT plugins in 2023: OpenAI opened a plugin marketplace, developers built integrations, adoption was uneven, and the whole system was eventually retired in favor of GPTs and then the current tool-calling infrastructure. The lesson from that experiment was that plugins need a clear value proposition and reliable execution semantics. A plugin that works 60% of the time is worse than no plugin, because the failure cases are unpredictable.
For a developer-focused tool, the target integrations are obvious: version control platforms, issue trackers, CI systems, deployment pipelines, database clients, documentation hosts. The value proposition for a GitHub plugin, for instance, is clear: the model can open PRs, read CI output, check issue status, and do all of this without the developer leaving the tool. Whether OpenAI has solved the reliability and permission scoping problems that plagued earlier plugin systems is not something the announcement makes clear.
Worth noting: the broader ecosystem has moved toward tool-calling with structured JSON schemas as the standard way for models to invoke external systems. MCP (Model Context Protocol), developed by Anthropic and now adopted fairly widely, provides a standardized way for AI tools to connect to external services. If Codex’s plugin system is built on something like this rather than a bespoke format, it will interoperate more naturally with the tooling developers already have.
Where This Sits in the Landscape
The coding tool space in 2026 looks nothing like it did in 2022. Then, the state of the art was context-aware autocomplete. Now, you have terminal agents (Claude Code, Codex CLI), IDE-integrated agents (Cursor, GitHub Copilot’s agent mode), and full desktop applications trying to absorb more and more of the development environment.
The desktop app approach trades composability for integration. A terminal agent is easy to script, combine with other tools, and run in CI. A GUI application gives you more surface area, but it is harder to automate and harder to fit into non-standard workflows. The bet OpenAI is making with the updated Codex app is that the integration is worth the trade-off for a significant number of developers.
Image generation is the one feature that feels slightly out of place in this framing. DALL-E integration in a code editor is useful for UI mockup work, generating placeholder assets, or prototyping visual designs. It is a real use case, but it is also the feature that makes Codex feel more like a general-purpose AI workspace than a developer-specific tool. That might be intentional.
The trajectory here is toward AI tools that try to handle more of the full-stack workflow: not just writing code, but reading documentation, interacting with external services, maintaining state across sessions, and operating other software on your behalf. Whether that consolidation produces better outcomes than a well-composed set of specialized tools is the experiment that the next year or two will actually answer.