The first Codex was a model, not an app. OpenAI released it in August 2021 as a code-specialized descendant of GPT-3, and its primary purpose was powering GitHub Copilot through an API. You could query it directly, watch it translate English to Python, and notice that training on GitHub repositories gave it a different character than general-purpose language models. OpenAI deprecated the standalone Codex API in March 2023; by that point, GPT-4 had made it redundant on every capability dimension, and maintaining a separate model brand for code made less sense.
The name came back as a desktop app, and the recent update to that app for macOS and Windows adds five features: computer use, in-app browsing, image generation, memory, and plugins. Each of these exists somewhere in the AI tooling ecosystem already. What’s worth examining is what combining them in a coding client actually changes, and where the real architectural shift lies.
The Feedback Loop Problem
AI coding tools have had a consistent structural limitation since Copilot launched. The loop works like this: the model suggests code, the developer runs it, observes the result, and manually translates what happened back into a prompt. The model never sees the running program. It writes in the dark, with the developer acting as interpreter between the code and its consequences.
Computer use changes this pattern. When a coding tool can interact with a running application, open a browser, read error output, and observe a rendered UI, it can close the feedback loop that previously required human intermediation. Anthropic added computer use to Claude in late 2024. OpenAI’s Operator product brought similar capabilities to general task automation. Adding it to a coding-specific context is the natural next step, and in some ways the most compelling application of the capability.
In practice, this means the tool can write a test, run it, see the failure, and iterate without you narrating what happened. It can open the browser, check how the rendered page looks, and notice that the CSS breakpoint is wrong. For tasks where the bottleneck is running the code and observing the output rather than writing it, computer use removes a round trip from the human. The loop is now shorter by design.
Cognition’s Devin, arguably the first well-publicized agent to apply computer use specifically to software engineering tasks, demonstrated this kind of autonomy before most coding tools supported it. The difference between Devin and what Codex is doing is one of positioning: Devin was framed as a fully autonomous contractor, while Codex is framed as an enhanced assistant you work alongside. The mental model matters for how the tool gets used, even when the underlying capabilities overlap.
What Memory Means in a Developer Context
Memory in ChatGPT has meant persistent facts across sessions: your name, your preferences, context you’ve asked it to retain. In a developer tool, the substance of what needs to be remembered is different. It is not that you prefer concise answers; it is that you are three weeks into building a service, your command handler lives in src/commands/, you made a deliberate choice to avoid class-based handlers in favor of module-level functions, and the last session ended with a half-finished refactor of the permission middleware.
Without memory, every new session starts cold. You re-explain the architecture, re-establish the constraints, re-provide the context that got you to where you are. Tools like Claude Code address this partly through CLAUDE.md files, which you maintain manually as living documentation of project decisions. Memory could automate that process, or at least augment it, by persisting what the tool learned during previous sessions.
The risk with automatic memory in a coding context is staleness. A manually maintained context file is intentionally curated; you decide what goes in it. Automatically persisted memory accumulates both good signal and bad, including decisions you have since reversed. How OpenAI handles memory curation, expiry, and correction for long-running projects will determine whether this feature is genuinely useful or just noisy context injection. This is an unsolved problem across the industry, and Codex’s implementation will be worth examining closely once real usage patterns emerge.
In-App Browsing and Image Generation
Browsing within the coding environment has an obvious use case: documentation lookup without context-switching. The less obvious use case is research during generation, where the model can look up a library’s API, check current package versions, or verify that a function signature has not changed in the latest release. Coding models have knowledge cutoffs that make live verification genuinely valuable. A model that can check current Rust crate documentation rather than relying on training data from a year ago is meaningfully more reliable on questions of specific API surface.
Image generation for developers is a narrower category than it sounds. Generating a UI mockup from a description, creating a diagram from an architecture spec, producing icon assets for a web app: these tasks exist in the workflow but have not historically belonged to the same tool as code editing. The integration is useful specifically when the image generation is grounded enough to serve as implementation reference, which requires the model to understand the connection between what it generates visually and what it generates as code. That connection is not guaranteed, but it is the right thing to aim for.
Plugins and the Platform Question
The plugin system is strategically the most significant feature on the list, though it also has the least visible surface area right now. The Visual Studio Code extension marketplace has over 50,000 extensions, and that ecosystem is a large part of why VS Code achieved the dominance it has. People build workflows around extensions and switching editors means losing them. An AI coding app with a plugin ecosystem creates the same kind of stickiness, but at a different layer. The plugins do not extend an editor; they extend the model’s capabilities and the app’s integrations.
If Codex develops a real plugin ecosystem, it shifts from being a tool to being a platform. Plugins for specific frameworks, internal company systems, CI pipelines, deployment targets: each integration makes the tool more valuable in the specific context where it is installed, and harder to replace. This is a different competitive play than raw model capability. Cursor, which has become a dominant choice for many developers, competes primarily on model quality and editor experience, not on a plugin marketplace. A plugin ecosystem is OpenAI competing on a dimension Cursor is not currently playing on.
Where This Sits in the Landscape
The AI coding tool landscape has several distinct approaches coexisting. Terminal-first tools prioritize codebase-level understanding and file-system access. Editor extensions like GitHub Copilot live inside existing workflows. IDE replacements rebuild the editor around AI. Desktop applications with computer use bundle AI assistance with the ability to observe and interact with running software.
Each approach has a different theory about where the friction in AI-assisted development actually lives. The terminal-first theory says friction is in context: the model needs deep access to the codebase. The editor extension theory says friction is in context-switching: keep the AI inside the existing tool. The IDE replacement theory says friction is in the editor itself: the entire editing environment should be redesigned around AI. The desktop app with computer use theory says friction is in the feedback loop: the model needs to see what the running code does.
The Codex update is a substantial step in that last direction. Computer use, memory, browsing, and plugins each address a distinct part of the workflow that pure code generation leaves unresolved. Whether they work well together in practice, and whether the implementation handles the hard cases cleanly, is a question that only real project usage can answer.