Codex Now Imports Cursor Skills. Portability Arrives

Agent skill portability got a concrete new data point on August 7, 2026, when Codex CLI 0.147.0 shipped with the ability to import Cursor-managed skills. The same changelog line adds a second, separate capability — synchronising changes to imported Claude and Cursor conversations without creating duplicates. Skills and conversations are different artifacts, and conflating them is the single easiest way to get this release wrong.

The reason it matters is not the feature itself. It is what the feature reveals about where lock-in has quietly been accumulating. Teams swap models freely now — that market is competitive and the switching cost is a config line. What does not swap freely is everything built around the model: the skills, the plugin catalogues, the project memories, the MCP server wiring, and the conversation history that encodes how a team actually works. A harness migration is cheap or expensive almost entirely based on that layer.

This piece does three things. It reads the 0.147.0 changelog line precisely, including the part most coverage will fuse together. It puts that line next to what Claude Code, Cursor and Codex each document about their own skill directories — which turns up an asymmetry the headline hides. And it converts the result into a short list of what to standardize now so a harness switch stays a weekend rather than a quarter.

The ChatGPT and Codex changelog entry for v0.147.0, dated August 7, 2026, lists the new capability in a single line that conjoins two distinct actions with an “and.” It is worth reading twice before drawing any conclusion from it, because the two halves have different subjects, different artifacts and different behaviour over time.

The first half is about skills, and its only named source is Cursor. The second half is about conversations, and it names both Claude and Cursor. The “without creating duplicates” behaviour — the ongoing synchronisation part — is stated for conversations. Nothing in that sentence says Codex keeps imported skills in sync after the import, and nothing in it says Codex imports skills from Claude Code.

That distinction is not pedantry. An import is a one-time or on-demand copy: whatever you pull in becomes yours to maintain in the new tool, and changes upstream do not follow. A synchronisation is a continuing relationship. Treating the skills half as if it inherits the conversations half’s sync semantics would lead a team to assume a shared source of truth that the vendor never claimed.

One more gap is worth flagging up front. Codex’s general skills-building documentation, as published at the time of writing, does not mention the Cursor-skill import or the conversation-sync behaviour at all. Both exist only in the 0.147.0 changelog entry. That means the mechanics — what exactly gets copied, what happens to a skill whose frontmatter Codex does not recognise, whether the import is repeatable — are not documented on the page a developer would naturally consult. Treat the changelog as evidence that the feature exists, not as a specification of how it behaves.

The most common error in coverage of a changelog line like this is reading it in isolation. Diff it against the entry seventeen days earlier and the shape changes. Codex CLI 0.145.0, dated July 21, 2026, already expanded /import to migrate Cursor and Claude Code settings, MCP servers, plugins, sessions, commands and project-scoped memories. Skills were conspicuously absent from that list.

So 0.147.0 is not Codex’s first cross-harness import feature. It is the release that closed one specific hole in a migration path that had been shipping incrementally for weeks. That reframes the story from “portability was invented on August 7” to “portability has been assembled piecemeal, and skills were the last obvious gap.”

The arithmetic is worth stating plainly, because it is the part a surface-level rewrite misses. July 21 to August 7 is 17 days. August 5 to August 7 is two days. Three documented releases inside 17 days, one of which was a single-line safety change. This is a product shipping at a cadence where the documentation surface cannot keep up with the changelog — which is exactly what we observed in section 01, and exactly why anything load-bearing should be verified against the vendor’s own page rather than a secondary summary.

On the 0.146.1 entry specifically: the changelog says safer automatic-review defaults were applied for cyber-capable models and that permission changes are explained in the terminal interface. It does not name which models, and it does not cite any triggering event. We are drawing no inference beyond what that one line states.

Community write-ups describe the /import flow as a manual command run once per project from a fresh Codex session, covering roughly six migration surfaces. That description is consistent with the vendor changelog’s own list, but it is third-party reporting of a terminal UX, not vendor documentation — so treat the step-by-step as reported rather than specified, and confirm the current flow in your own install before writing it into a runbook. If you want the surrounding Codex configuration model, our deep dive on Codex CLI config profiles and sandboxing covers the layers /import is writing into.

Here is the finding that reframes the headline. Cursor’s own skills documentation states that it loads skills from .agents/skills and .cursor/skills at project level and from the home-directory equivalents globally — and, explicitly for backward compatibility, from .claude/skills, .codex/skills, ~/.claude/skills and ~/.codex/skills as well.

Read that again with the release date in mind. Cursor has been reading Claude Code’s and Codex’s skill directories directly, with no import step and no user action, independent of anything Codex shipped in August. Cross-harness skill compatibility did not arrive on August 7. It already existed — passively, in one direction, as a unilateral compatibility decision by a single vendor.

Counted as locations rather than prose, the asymmetry is immediate. Cursor documents eight skill directories it will read: four of its own and four belonging to other vendors. Claude Code documents four locations, all its own. Codex documents four scopes, all its own. Only one of the three has decided to look outside its own namespace by default.

Put the two mechanisms side by side and they are not the same kind of thing at all. Cursor’s is passive and continuous: the file stays where it is, and Cursor finds it. Codex’s is active and point-in-time: you run a command, and a copy lands in Codex’s own namespace. The first costs nothing to maintain and creates no second copy. The second creates a fork the moment the original changes — which is precisely the drift problem that the conversation half of the changelog line solves for transcripts, and that the skills half does not claim to solve for skills.

None of this is a file-format problem. All three tools sit on the same open standard: a skill is a folder containing a SKILL.md file, and that file carries metadata — at minimum a name and a description — plus instructions telling an agent how to perform a task. The standard’s own overview says the format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products; its client showcase lists dozens of adopting tools, including Cursor, Claude Code and ChatGPT and Codex alongside GitHub Copilot, VS Code and Gemini CLI.

Where portability actually breaks is one layer up, in the vendor-specific frontmatter each tool has added on top of the shared minimum. Claude Code’s documentation is unusually honest about this: it publishes a compatibility table marking exactly which of its fields survive outside Claude Code. Six do. Everything else is a Claude Code extension.

Six of eighteen is the number to carry. Two-thirds of Claude Code’s documented frontmatter surface does not travel, and the third that does is almost entirely descriptive — a name, a description, a licence, a compatibility declaration, free-form metadata, and one tool-permission field. Every field that expresses how the skill behaves — which model, how much effort, which subagent, which hooks fire — lives outside the portable set. That is not a criticism of Claude Code; the extensions exist because the shared standard is deliberately small. It is simply where the switching cost lives, and it is now countable rather than impressionistic.

The practical consequence for anyone authoring skills today is direct. If a skill is meant to outlive your current harness, keep its frontmatter inside those six fields and push everything else into the instruction body, where it is prose an agent reads rather than a key a parser rejects. Our step-by-step guide to building a skill from scratch walks the authoring side of that trade-off in detail.

The skills line was not the largest change in 0.147.0. The same entry adds portable Agent Plugins with search across local, personal, workspace and remote plugin catalogues; automatically reviewed approvals via a new --approve-for-me flag; and opt-in support for the MCP 2026-07-28 protocol including paginated discovery, multi-round requests and non-blocking server startup. It also enables cached web search and remote conversation compaction for Amazon Bedrock, and bumps the MCP SDK to 3.0.0, Ratatui to 0.30.2 and V8 to 150.4.0. One removal is easy to miss: a legacy blanket-automation flag was dropped from codex exec, with the changelog pointing users at --sandbox workspace-write instead.

The Agent Plugins half of that list is the distribution mechanism for skills rather than a competing format — Codex’s own documentation draws the line as skills being the authoring format and plugins being how they are distributed. We covered that standard in depth in our piece on what Agent Plugins 1.0 actually fixes, so we will not restate it here.

Why does an MCP protocol revision belong in a piece about skill portability? Because it is the same problem wearing different clothes. Multi Round-Trip Requests replace the old server-initiated request pattern — servers now return a result whose inputRequests field carries what else they need, and clients answer with inputResponses on a retry of the original request. Non-blocking server startup matters for exactly the same reason paginated discovery does: an agent CLI now routinely juggles many MCP servers at once, and a team’s MCP wiring is as much a migration surface as its skills are. Both are config that took months to get right and that no one wants to rebuild.

One more scheduled change belongs on the calendar rather than in this analysis: the changelog announced on July 31, 2026 that GPT-5.4 and GPT-5.4 mini will no longer be available in Codex for users signed in with ChatGPT from August 31, 2026, remaining available on the OpenAI API and in API-key-authenticated Codex sessions, with gpt-5.6-terra and gpt-5.6-luna named as the recommended replacements. That is an announced schedule, not yet in effect at the time of writing. Separately, and only as context, OpenAI announced that its standalone Atlas browser was scheduled to stop working on August 9, 2026 as browser-based agentic capabilities fold into ChatGPT and Codex — a different product from the CLI, and not part of the skills story.

Two years ago the switching-cost conversation was about models. Today that is the cheapest thing to change in the stack — most harnesses front several vendors, and swapping the default is a configuration line. The cost migrated. It now sits in the scaffolding a team builds around whichever model it happens to be using: the skills, the plugin catalogues, the project-scoped memories, the MCP server definitions, the approval policies, and the conversation history that quietly encodes how the team works.

That is why a changelog line about importing skills is more interesting than its size suggests. Every item on Codex’s /import list — settings, MCP servers, plugins, sessions, commands, project-scoped memories, and now skills — is an admission of where the friction actually is. Vendors do not build migration tooling for things that are easy to move.

The direction of travel is worth projecting carefully, because the evidence supports a trend but not a destination. Three separate vendors have now published skill systems on the same open format inside a single ecosystem, one of them reads two competitors’ directories by default, and another has built an explicit migration command that keeps growing. Nothing here quantifies how many teams actually use cross-harness import — no source measures that, and the existence of a feature is not evidence of its adoption. What the evidence does support is that the shared surface is small, the vendor-specific surface is large, and the pressure is currently on the vendors to bridge rather than on authors to converge. If that holds, the practical question for a team stops being “which harness wins” and becomes “how much of our scaffolding sits above the shared six fields.”

None of this requires picking a winner. It requires knowing which parts of your setup are portable by construction and which parts are a bet on one vendor — and then making that bet deliberately, in the places where the vendor extension genuinely earns its keep.

Two things worth adding to the same review. First, distribution is becoming its own surface: skills are increasingly bundled, versioned and installed rather than copied by hand, which brings a package ecosystem’s conveniences and a package ecosystem’s risks — the subject of our companion piece on skill packs starting to look like a package ecosystem. Second, approval and permission defaults are moving fast across every harness right now, and Codex’s new --approve-for-me flag lands in the same week that Claude Code prepares to make auto mode the default. Whatever you standardize on skills, standardize the approval posture alongside it.

If your team is running two or three of these harnesses in parallel and nobody can currently say which of your skills would survive a switch, that inventory is a short exercise with a durable payoff. It is the kind of scoping work our AI transformation engagements open with: catalogue what exists, separate the portable from the vendor-coupled, and decide the coupling deliberately rather than by accretion.