# What Changed in the New Codex: Why It Feels More Like a Dev Environment

> Canonical: https://vxi.me/en/posts/what-changed-in-the-new-codex/
> Locale: en-us
> Published: 2026-03-27
> Updated: 2026-03-27
> Markdown: https://vxi.me/en/posts/what-changed-in-the-new-codex.md

If your picture of Codex is still stuck around May 2025, coming back to it now can feel a little disorienting. It no longer reads like the same kind of product.

Back in [OpenAI’s May 16, 2025 launch post for Codex](https://openai.com/index/introducing-codex/), the framing was pretty clear: Codex was a cloud-based software engineering agent. That was already a big deal, but the mental model many developers took away from it was still simple enough. You handed it work, it ran in the cloud, and it came back with results. The center of gravity was still task execution.

That is not the whole picture anymore. What changed is not just that it can code a bit better. The bigger shift is that the product has started to grow around workflow: terminal, IDE, desktop app, skills, automations, multiple agents, worktrees, persistent entry points. Once those pieces show up together, Codex stops feeling like a one-off coding agent and starts feeling more like a development environment entry layer.

If you are a developer, or one of the many people doing some form of vibe coding now, that distinction matters. It changes how you use the tool. You stop treating it as something that merely answers prompts, and start treating it as something that can gradually absorb parts of how you work.

## The timeline makes the shift pretty obvious

I think this is easiest to see if you stop looking for one flashy feature and just line up the product milestones.

- On May 16, 2025, OpenAI published [Introducing Codex](https://openai.com/index/introducing-codex/). The emphasis was on a cloud software engineering agent that could take on coding tasks in an isolated environment.
- On September 15, 2025, OpenAI published [Introducing upgrades to Codex](https://openai.com/index/introducing-upgrades-to-codex/). That is where the experience starts looking more unified across terminal, IDE, web, and phone.
- On February 2, 2026, OpenAI published [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/). At that point the product shape becomes much clearer: app, parallel agents, worktrees, task inbox, skills, automations. It starts to read less like a chat surface and more like a command center.
- On March 4, 2026, OpenAI added Windows support as well. That makes the multi-surface direction even harder to miss.

So if someone says “the new Codex added skill and plugin-like app features,” I get what they mean, but I still would not describe it as a classic plugin system. A safer description is that Codex is moving from a single agent experience toward a more reusable, integratable, orchestrated developer workflow layer. OpenAI’s own language is closer to `Skills`, `Automations`, app surfaces, and IDE integration than to a traditional plugin marketplace.

## Skills are probably the most important practical change

When people compare AI coding tools, they usually start with model strength: code quality, latency, whether it can finish a task end to end. All of that matters, but it is not the part I find most interesting here.

The part that matters more over time is the stuff you do not want to explain over and over again. Repo rules, coding standards, review style, deployment constraints, risky-operation checks, project-specific conventions. In older workflows, most of that had to live inside long prompts, repeated every time, and it was never especially stable.

That is why `Skills` matter. They are not just another feature bolted onto the model. They let you package a repeatable way of working into something you can call again. For a team, that means process can be captured instead of re-explained. For an individual, it means less prompt waste and less drift.

This is also why people instinctively compare the idea to plugins. The comparison is understandable, but only up to a point. A classic plugin usually means “install a capability.” A skill is closer to “preserve a method.” It is not just about adding a button. It is about teaching the tool how this particular environment expects work to be done.

That distinction matters to both audiences in different ways. Developers care because they want the tool to respect the repo instead of freewheeling through it. Vibe coding users care because they are tired of rebuilding context from scratch every single time.

But stopping at skills would undersell what changed. OpenAI now has a dedicated plugin layer for Codex, and the official framing is more concrete than a lot of people expect. In the [Codex Plugins docs](https://developers.openai.com/codex/plugins), plugins are described as installable bundles for reusable Codex workflows. That wording matters. This is not “add a tiny extension and move on.” It is a packaging model for shipping repeatable ways of working.

![Official Codex plugin directory screenshot](https://developers.openai.com/images/codex/plugins/directory.png)

The screenshot above is a pretty good clue by itself. The new Codex is no longer just “you can write a few skill files if you want.” It now has a plugin directory, install surfaces, categories, and workflow-oriented entries. When GitHub, Slack, Linear, Figma, Netlify, Cloudflare, and Sentry all show up inside one directory, the product stops feeling like a coding chatbot and starts feeling like an environment with distribution built in.

What matters even more is what a plugin can bundle. According to the docs, a plugin can package three different layers together:

- skills
- apps, meaning optional app integrations or connector mappings
- MCP servers for shared tools or context

That is why I keep describing this as a developer-environment shift rather than a raw model upgrade. Once plugins exist, reusability stops living only at the prompt layer. Teams can package a workflow instead of re-explaining it. Individuals can keep their own toolchain behavior portable instead of rebuilding it from scratch.

## Plugins are what turn skills into something you can actually distribute

This is probably the most underrated part of the update.

Before this, even a very good skill often stayed personal. You might know how to store it, invoke it, and reuse it locally, but that did not automatically make it easy for someone else to discover or install. The plugin layer changes that.

The official structure is pretty explicit. A minimal plugin starts with `.codex-plugin/plugin.json` as its entry point. From there, the plugin root can also include:

- `skills/`
- `.app.json`
- `.mcp.json`
- `assets/`

That is developer-friendly in a very practical way. It means you are no longer sharing a floating prompt hidden in a note. You are sharing a package with a manifest, metadata, bundled capabilities, optional install-surface copy, and even screenshots. The docs go all the way down to fields like `displayName`, `shortDescription`, `defaultPrompt`, `brandColor`, and `screenshots`, which tells you this is already being treated as a real install and discovery surface, not a vague future concept.

There is another useful detail in the docs: OpenAI is not limiting plugins to the official directory. Codex can read plugin marketplaces from three places:

- the curated OpenAI directory
- `$REPO_ROOT/.agents/plugins/marketplace.json`
- `~/.agents/plugins/marketplace.json`

That detail matters more than it first appears. It means you can build a repo-local marketplace for team workflows, project-specific skills, and connector bundles without waiting for some public ecosystem story. For solo developers and small teams, that is probably the most realistic version of value anyway.

OpenAI even ships a built-in `@plugin-creator` skill to scaffold local plugins. I like that detail because it shows the feature is already meant to be used, not just talked about.

![Official plugin-creator skill screenshot](https://developers.openai.com/images/codex/plugins/plugin-creator.png)

One more official signal is worth mentioning. In the [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/) post, OpenAI says overall Codex usage has doubled since GPT-5.2-Codex launched in mid-December, and more than one million developers used Codex in the past month. That helps explain why packaging and distribution suddenly matter so much. Once usage reaches that scale, “just write a good prompt” stops being enough. Reusable workflow layers become product infrastructure.

## The old-vs-new split is really about workflow memory

My own read is pretty simple.

Older Codex felt like a very capable cloud agent you could hand work to. It was useful, sometimes impressively so, but it still behaved like outside help. A lot of context was tied to the moment. When the task ended, you often had to start over next time with fresh instructions.

The newer Codex feels like it is aiming at something else. It still takes tasks, obviously, but it also starts taking rules, surfaces, routines, and recurring actions. You can move across entry points. You can keep reusable skills around. You can delegate recurring work to automations. The whole shape is more persistent.

For developers, that lowers engineering friction. You spend less time re-describing the repo and more time pushing actual work forward. For vibe coding users, the difference is just as noticeable. A lot of people did not really struggle with ideas; they struggled with having to reconstruct the same setup on every run. Reusability changes that.

There is another important shift underneath all of this. A lot of older AI coding experiences felt like “strong model, thin environment.” The newer Codex is clearly trying to fix the second half of that sentence. It is not only trying to prove that it can write code. It is trying to prove that it can operate inside a more realistic development loop.

That is a much bigger change than it looks at first glance.

## If you used Codex before, it makes sense to reframe it now

I would look at the new Codex a little differently now.

Do not judge it only by whether it can write one function or finish one toy feature. That misses the real movement. The better question is whether it can take in your working rules and keep reducing repeated setup.

And if what you mean by “plugins” is really “ways to extend or attach workflow,” then it makes more sense to look at `Skills`, `Automations`, IDE integration, and the app surfaces than to go hunting for a classic extension store. The new direction is closer to an integration layer than a plugin catalog.

After reading the official plugin docs, I would push that one step further. The new Codex is no longer merely “plugin-like.” It already has a real plugin packaging and marketplace model. It just does not map one-to-one onto the browser-extension or VS Code-extension mental model. It is much closer to workflow bundles and integration packages.

That is why I think this matters for both developers and vibe coding users. The interesting part is not just that Codex got better at answering. It is that it is starting to behave more like a place where work can continue. Once that happens, the value is no longer just in one response. It is in the accumulated way the tool fits your process.

That is the real upgrade to me. Not that it writes slightly faster, but that it is getting better at holding onto how you work.