Record and Replay turns a single demo into a reusable Codex skill

OpenAI shipped a feature on June 18, 2026 that changes how people teach Codex to do work. It is called Record & Replay, and the premise is almost too simple to need explaining. You perform a task once on your Mac, Codex watches, and it writes a reusable skill that can run the same workflow again on its own. There is no scripting step, no configuration file to hand-edit before anything happens, and no need to describe the task in a long prompt. You show it, and Codex turns the demonstration into something it can repeat.

OpenAI turns a demonstrated Mac workflow into a reusable Codex skill

The feature lives inside the Codex desktop app and sits on top of Computer Use, the capability that lets Codex see a screen and operate graphical applications by moving the pointer, clicking, and typing the way a person does. Record & Replay is the recording layer that sits over it. During a recording, Codex observes the actions and the window content it needs to understand the workflow. When you stop, it inspects what it captured and drafts a skill that explains when to use the workflow, what inputs it needs, the steps to follow, and how to check that the result is correct.

OpenAI frames the use cases in plain operational terms. You might record how you file an expense report, book a parking space, create a correctly configured issue, publish a video, or download a recurring report. The pattern that ties these together is repetition. Each is a task you already know how to do, where the steps are stable and the definition of success is clear, but where doing it by hand every time is a drain. Record & Replay is built for exactly that category of work, and OpenAI is explicit that it works best when the steps are predictable and the success criteria are obvious before you start.

The output is not a black box. The skill Codex generates is a plain file you can open, read, edit, and refine. This matters more than it first appears, and it connects Record & Replay to a much larger shift in how AI agents are configured across the industry. The skill format Codex writes into is the agent skills open standard, a specification Anthropic released in December 2025 and that OpenAI, Google, Microsoft, GitHub, and others adopted within weeks. A workflow you demonstrate to Codex becomes a portable artifact in a format that other tools can read, not a proprietary recording locked to one vendor.

Availability is narrow at launch, which is the detail most likely to frustrate readers outside the United States. Record & Replay is macOS only. There is no Windows version yet, even though Codex itself runs on Windows and gained Computer Use there in late May 2026. The initial rollout also excludes the European Economic Area, the United Kingdom, and Switzerland, the same geographic carve-out OpenAI has applied to several of its more aggressive Codex capabilities. Computer Use must be available and enabled before Record & Replay appears at all, and in organizations that manage Codex centrally, a single configuration flag controls both features together.

What makes this launch worth a close look is not the mechanics of recording a screen. Screen recorders are old. Macro tools that replay clicks are older still. The interesting part is that Codex is not just replaying coordinates. It is interpreting what it watched, generalizing the workflow into editable instructions, identifying which values are inputs that change between runs, and producing something a human can inspect and correct. That places Record & Replay at the meeting point of three separate histories: decades of research into teaching computers by demonstration, twenty-five years of robotic process automation in enterprises, and the very recent arrival of general-purpose AI agents that can operate a desktop. This analysis works through all three, along with the security exposure, the privacy questions, the business impact across sectors, the realistic limits, and the strategic reason OpenAI is building this at all.

The idea behind show, don’t tell automation

Most automation has always demanded that you translate a task into a language the machine understands. You write a script. You build a flowchart. You drag activities onto a canvas and wire them together. You describe, in some formal or semi-formal way, the thing you already know how to do with your hands. That translation step is where automation projects stall. People who know the work rarely want to learn the tooling, and people who know the tooling rarely understand the work well enough to capture its quiet exceptions.

Record & Replay removes the translation step for a useful slice of tasks. The demonstration is the specification. You do the work, and the act of doing it is what teaches Codex the workflow. OpenAI’s own framing for the feature is “show Codex a workflow once and turn it into a reusable skill,” and that phrasing is precise rather than promotional. The recording is the input. The skill is the output. Nothing in between requires you to write instructions in any language other than the actions you already perform.

This is a meaningful inversion of the prompt-first model that has dominated AI tools for the last few years. Prompting asks you to describe a task well enough that a model can infer what you want. For some tasks that works beautifully. For tasks that depend on layout, on the exact sequence of clicks in a clunky internal portal, or on small preferences that you would never think to write down, description is a poor fit. You cannot easily prompt your way through a legacy expense system whose buttons are in unexpected places and whose required fields change depending on the category you select. Showing the system, by contrast, captures all of that without you having to articulate any of it.

OpenAI is careful to mark the boundary of when this approach fits. The feature is recommended when a workflow is repetitive, depends on your preferences, or is easier to show than to describe. The third condition is the honest one. Some tasks genuinely are easier to demonstrate than to explain, and those are the tasks where Record & Replay earns its place. A one-off task is not worth recording. A task that changes shape every time you do it will not generalize cleanly. The sweet spot is the stable, repeated, mildly tedious work that fills the edges of a working day.

There is a quieter design decision worth naming. The skill Codex produces after watching you is inspectable and editable, not an opaque recording you have to trust blindly. After it drafts the skill, you can read exactly how Codex understood the workflow, and you can correct it. You can call out a naming convention it missed, a field default it should always apply, or a decision point where the right action depends on what it sees. This refinement loop is the difference between a recording that happens to work once and a skill that holds up across many runs with different inputs. The demonstration gets Codex most of the way there. The editing closes the gap on the preferences and edge cases a single demonstration could never reveal.

The phrase “show, don’t tell” comes from writing advice, where it means dramatizing rather than explaining. Applied to automation, it captures something real about why this feels different. You are not telling Codex what to do. You are letting it watch you do it, then handing it a written version of what it saw so you can fix the parts it got wrong. That combination, demonstration plus an editable written artifact, is what separates this from both the dumb macro recorders of the past and the prompt-only agents of the present.

Recording a workflow inside the Codex app step by step

The recording flow is short, which is the point. Inside the Codex app you open Plugins, open the + menu, and select Record a skill. Codex then offers a suggested prompt describing what it is about to capture. You review that prompt, add any context that would help, and submit it. Before recording starts, Codex asks for permission to record your actions, and you approve that request only once you are actually ready to begin. From there you perform the workflow on your Mac exactly as you normally would. When the task is finished, you stop the recording from the menu bar, from an on-screen overlay, or simply by telling Codex you are done.

The context you give before recording does real work, and skipping it is the most common way to get a weak skill. OpenAI’s guidance is to tell Codex your goal and any specific inputs that might vary between uses before you start. If you are recording how you file an expense, the amount, the vendor, and the date will change every time, while the navigation path and the required fields stay the same. Naming the variable inputs up front helps Codex separate the parts of the workflow that are fixed from the parts that are parameters. A recording made without that framing tends to bake in the specific values you happened to use, which produces a skill that only repeats your exact demonstration rather than generalizing it.

During the recording itself, Codex is observing the actions and the window content it needs to learn the workflow. It is not simply logging mouse coordinates. It is watching what you click, what you type, and what the application shows in response, building an understanding of the sequence and the on-screen state at each step. Recording continues until you stop it, so the discipline that matters most is keeping the session focused. OpenAI’s advice is blunt about this: stop recording when the workflow is complete, rather than continuing into unrelated cleanup. A recording that wanders into checking email, reorganizing files, or fixing something unrelated teaches Codex noise it then has to be edited out of.

The instruction to use realistic inputs but avoid secrets and sensitive data deserves emphasis, because it sits at the center of the feature’s risk profile. You want to demonstrate the real workflow with real-looking values so Codex learns the actual task, not a sanitized fiction. At the same time, whatever appears on your screen during a recording is captured, which means passwords, API keys, personal identifiers, and confidential records should never be visible while you record. This is a behavioral safeguard rather than a technical one. Codex does not automatically know which numbers on your screen are a corporate card and which are a public invoice total, so the responsibility for keeping secrets out of frame rests with the person recording.

After you stop, Codex does the part that distinguishes this from a macro recorder. It inspects the captured workflow and drafts a skill that explains four things: when the workflow should be used, what inputs it requires, what steps to follow, and how to verify that the result is correct. That fourth element, the verification step, is what lets a replay confirm it actually accomplished something rather than blindly executing and reporting success. You can then ask Codex to refine the skill further, tightening the instructions, adding preferences it could not have inferred, and handling decision points the single demonstration did not surface. The recording is the raw material. The drafted skill is Codex’s interpretation of it. The refinement is where you make it reliable.

The whole loop is meant to take minutes, not the days a comparable RPA automation might consume. That speed is the feature’s strongest argument, and it is also the reason the quality of the recording matters so much. A fast tool that captures a sloppy demonstration produces a sloppy skill quickly. The same tool, fed a focused demonstration with clear context, produces something genuinely useful in the same amount of time.

Inside the skill Codex writes after watching you work

The artifact at the heart of Record & Replay is a skill, and understanding what that file contains explains why the feature is more than a recording. In OpenAI’s terms, a skill packages instructions, resources, and optional scripts so Codex can follow a workflow reliably. It is the authoring format for reusable work. The skill Codex drafts from your demonstration is the same kind of object a developer might write by hand, except that Codex assembled it from watching you rather than from your typing.

A skill is structured around a single markdown file called SKILL.md. At the top sits a small block of metadata in YAML format, which always includes a name and a description and may include optional fields. Below that, in plain markdown, are the instructions themselves. The folder can also hold supporting material, such as scripts the workflow runs or reference files it consults, kept separate from the main instructions. This structure is deliberately minimal. It is just enough to make a skill discoverable and portable without dictating what the skill can do.

When Codex writes a skill from your recording, it fills that structure with four functional parts. It states when to use the workflow, which becomes the description Codex later reads to decide whether a skill is relevant to a new request. It lists what inputs the workflow needs, the values that change between runs. It records the steps to follow, the sequence it learned from watching you. And it defines how to verify the result, the check that confirms the task actually completed. That last component is what separates a skill from a script. A script runs and stops. A skill knows what success looks like and can confirm it reached that state.

The decision to write skills into an open, human-readable format rather than a proprietary binary has consequences that go beyond convenience. Because the skill is plain text, you can read precisely how Codex understood your workflow. If it misinterpreted a step, you see the misinterpretation in the file and fix it. If it failed to capture a preference, you add the preference in plain language. This transparency is the practical answer to the trust problem that has always dogged automation: people are reasonably reluctant to hand a task to a system they cannot inspect, and a readable skill removes that objection. You are not trusting a recording. You are reviewing an editable document that describes what the agent will do.

Codex manages skills using progressive disclosure, a design that keeps its working memory lean. It begins with only each skill’s name, description, and file path held in context. It loads the full SKILL.md instructions only when it decides a skill is relevant to the task at hand. For a user with many recorded skills, this means Codex is not carrying the full text of every workflow in every conversation. It carries a lightweight index and pulls in the detail of a specific skill only at the moment it needs it. This is the same mechanism that lets the format scale to hundreds of skills without overwhelming the model’s context window, and it is one of the reasons the agent skills standard spread so quickly across competing tools.

There is also a distinction OpenAI draws between skills and plugins that matters for anyone planning to share what they record. Skills are the authoring format for a workflow. Plugins are the installable distribution unit. A skill you record is best suited to local use or use within a single project. If you want to distribute it across a team as a stable package, bundle it with other skills, ship it alongside an app integration, or attach configuration like MCP servers, you package it as a plugin instead. Record & Replay is the fast path to a working skill. Turning that skill into something an organization installs and maintains is a separate, more deliberate step.

Replaying a skill with new inputs in a fresh thread

Recording is half the feature. Replaying is the half that delivers the value, and OpenAI keeps the mechanics deliberately ordinary. You start a new thread and ask Codex to use the generated skill. You give it the values that are different this time, such as the file to upload, the issue to create, or the date range for a report. Codex treats the skill as reusable context for the task and completes the workflow with whatever tools are available in the current environment.

The phrase “with the tools available in the current environment” is more important than it sounds. A replayed skill is not a rigid recording that breaks the moment anything shifts. Codex can complete the workflow using Computer Use, browser actions, installed plugins, or a combination of them. If part of the task is best handled by clicking through a desktop app, it uses Computer Use. If part is a web flow, it can use browser actions. If a connected plugin offers a cleaner path to the same outcome, it can take that path instead. The skill describes the workflow and its goal; Codex chooses how to accomplish it given what it has access to at replay time.

This is the conceptual break from traditional macro replay. A macro recorder captures a fixed sequence of inputs and plays them back identically, which works only as long as the screen looks exactly as it did during recording. Move a window, resize an element, or change a layout, and the macro misfires. Because Codex understands the workflow as a set of steps with a goal and a verification check, it has room to adapt. It is aiming at an outcome it can recognize, not blindly reproducing coordinates. That adaptability is real but bounded, and the section on failure modes later in this analysis treats its limits honestly, because a feature that adapts can also adapt in the wrong direction.

Supplying the variable inputs at replay is where the up-front context pays off. If the skill was recorded with a clear sense of which values change, you can hand Codex new values naturally and it will slot them into the right places. The inputs you name when recording become the parameters you provide when replaying. A skill for downloading a recurring report might take a date range. A skill for creating an issue might take a title, a description, and a label. A skill for publishing a video might take the file and the metadata. The cleaner the separation between fixed steps and variable inputs in the recorded skill, the smoother the replay.

The replay also inherits the verification step Codex wrote into the skill. After running the workflow, Codex can check whether the result matches what success should look like, which catches a category of silent failures that plague unattended automation. A bot that submits an empty form and reports success is worse than useless. A skill that knows what a completed submission looks like can tell the difference. This does not make replay infallible, and the verification is only as good as the check Codex inferred and you refined, but it is a structural improvement over fire-and-forget execution. Reusing a skill across many runs with different inputs is the entire economic case for recording one in the first place, and the verification step is what makes that reuse trustworthy enough to leave running.

Computer Use sits underneath everything Record and Replay does

Record & Replay cannot exist without Computer Use, and the relationship between the two is worth making explicit because it shapes both the feature’s power and its risk. Computer Use is the capability that lets Codex see and operate graphical user interfaces. With it, Codex can look at what is on screen, move the pointer, click, and type into applications the way a person does. Record & Replay is the recording and generalization layer built over it. Without Computer Use enabled, the feature does not appear at all.

OpenAI added Computer Use to the macOS Codex app in April 2026, as part of a broad update the company described as turning Codex into an agent for nearly everything rather than a coding tool alone. On macOS, Codex runs Computer Use in the background, a design that lets agents operate Mac applications with their own cursors, in parallel, without taking over what the user is doing in the foreground. That background model is unusual and important. It means Codex can drive an application while you continue working in another window, rather than seizing your machine for the duration of a task.

To see and interact with applications on macOS, Codex needs specific operating-system permissions. It requires Screen Recording permission so it can see the target app, and Accessibility permission so it can interact with it. These are the same permissions any legitimate automation or screen-capture tool requests, and granting them is what allows Computer Use, and therefore Record & Replay, to function. They are also the permissions that make the privacy conversation unavoidable, because Screen Recording access is exactly what it sounds like. A tool with that permission can see whatever is displayed.

The dependency runs deep enough that OpenAI ties the two features together in enterprise configuration. In organizations that manage Codex with a requirements.toml file, the [features].computer_use requirement controls Record & Replay as well. Setting computer_use = false makes both features unavailable at once. There is no way to allow Record & Replay while disabling Computer Use, because the recording feature is meaningless without the underlying ability to see and operate the screen. For administrators, this is a single decision with a single switch, which is cleaner than managing two related capabilities separately but also means the choice is all or nothing.

Understanding this layering clarifies what Record & Replay actually contributes. The hard technical capability, operating arbitrary desktop and browser applications visually, already existed in Computer Use. What Record & Replay adds is a way to teach Codex specific workflows by demonstration and to capture them as reusable skills, rather than describing each task in a prompt every time. It is the configuration interface for a capability that was already present. That framing matters when comparing it to competitors, because several rival products have computer-use abilities of their own; the question is whether they offer an equally low-friction way to capture and reuse specific workflows, which most do not yet do through demonstration.

The flip side of building on Computer Use is that Record & Replay inherits all of Computer Use’s risks. Any concern about an agent that can click, type, and operate applications autonomously applies in full to the skills Record & Replay produces, because those skills run through the same machinery. A recorded skill is a stored, repeatable instruction set for an agent with hands on the machine. That is the source of both its usefulness and the security exposure examined later in this analysis.

macOS first, with foreground and background differences that matter

The platform story behind Record & Replay is not just “macOS only.” It reflects a real technical gap between how Codex operates a Mac and how it operates a Windows PC, and that gap explains why the recording feature launched where it did.

On macOS, Codex introduced background computer use in April 2026. The design lets multiple agents work on Mac applications in parallel, each with its own cursor, without interrupting anything the user is doing in the foreground. You can hand Codex a task and keep working, because the agent operates in a layer that does not seize your active session. This background capability is what makes recording and replaying a workflow comfortable on a Mac. You can demonstrate a task, and later let a replay run, without surrendering control of your machine for the duration.

Windows works differently. OpenAI brought Computer Use to the Codex app on Windows on May 29, 2026, in version 26.527, and the constraint there is significant. On Windows, Computer Use runs in the foreground. The agent takes over the active desktop session for the duration of the task, moving the pointer, typing into applications, and controlling foreground input. If you plan to keep working on the same machine while Codex operates, on Windows you cannot. Windows has no equivalent background-session capability at this time, so an agent task and a human user contend for the same desktop.

That difference is the most plausible technical reason Record & Replay is macOS only at launch. A recording-and-replay experience that requires the agent to seize your screen every time it replays is far less appealing than one that runs quietly in the background. The macOS background model fits the feature; the Windows foreground model does not, at least not yet. OpenAI has not committed to a Windows version of Record & Replay, and the foreground constraint suggests it would need either the same background capability on Windows or a different interaction model before the feature would feel comparable.

The macOS-first decision drew predictable criticism. Among the early reactions to the launch, the most common complaint was precisely the macOS-only limitation, from Windows users who run Codex and have Computer Use but cannot record skills. For a company positioning Codex as a general automation agent for everyday computer work, shipping the marquee automation-authoring feature on one operating system only is a real gap, and one that disproportionately affects enterprise environments where Windows dominates the desktop. Developers may skew toward Macs, but the finance, operations, and support teams who would benefit most from recording routine workflows are far more likely to be on Windows.

For now, the practical reading is straightforward. If you are on a Mac, have Computer Use enabled, and are outside the excluded European regions, Record & Replay is available to you. If you are on Windows, you have Computer Use but not the recording feature, and you will continue to configure skills the way you did before, by writing or installing them rather than demonstrating them. The capability gap between the two platforms is narrower than it looks at the level of raw computer use, but the authoring experience is meaningfully different, and that difference is what Record & Replay exposes.

Europe, the UK and Switzerland sit outside the initial rollout

The geographic exclusion attached to Record & Replay follows a pattern OpenAI has repeated across its most capable Codex features, and the precise wording matters. According to OpenAI’s Codex changelog, the initial availability of Record & Replay excludes the European Economic Area, the United Kingdom, and Switzerland. OpenAI’s feature documentation phrases the same exclusion in terms of Europe more broadly. Either way, the practical effect is that users across the European Economic Area, in the UK, and in Switzerland do not get the feature at launch.

This is not an isolated decision. When OpenAI brought Computer Use to Windows in late May 2026, the same regions were excluded at launch. When the company rolled out personalization features such as context-aware suggestions and memory on macOS in April 2026, those capabilities were described as coming to EU and UK users later rather than immediately. Memory in Codex is off by default in the European Economic Area, the UK, and Switzerland. A clear pattern has formed: OpenAI ships its most autonomous and most data-intensive Codex capabilities first in markets with lighter or clearer regulatory expectations, then extends them to Europe once the compliance picture is settled.

The likely reasons are regulatory rather than technical. Features that involve an AI agent operating a user’s computer, recording screen activity, and remembering preferences sit squarely in territory governed by European data protection law and the European Union’s AI Act. Screen recording and the capture of on-screen content raise data protection questions under the General Data Protection Regulation, particularly around what is collected, how it is processed, and how long it is retained. An agent that watches a workflow may incidentally capture personal data belonging to the user or to third parties, and the legal basis for that capture, along with the safeguards around it, is exactly the kind of thing a careful company resolves before launching in a strict jurisdiction.

The AI Act adds a second layer. It imposes obligations that scale with the risk a system presents, and an autonomous agent operating desktop applications on a user’s behalf is the sort of high-capability system that draws scrutiny. Rather than launch into uncertainty and risk a costly misstep, OpenAI has consistently chosen to delay European availability of its most agentic features. The European exclusion is best read not as a verdict on European users but as a calculation about regulatory risk, and the company’s track record suggests these features tend to reach Europe eventually, often with additional defaults and controls.

For European businesses, the practical consequence is a lag. Teams in the EEA, the UK, and Switzerland that would benefit from recording routine workflows have to wait, and in the meantime competitors in other markets get a head start on building libraries of reusable skills. That timing gap is a recurring cost of Europe’s regulatory posture, and it cuts both ways: stronger protections for users, slower access to the tools. Whether the eventual European version of Record & Replay arrives with the same capabilities or with additional restrictions is one of the open questions this launch leaves unresolved.

The agent skills standard Anthropic opened and OpenAI adopted

The most underappreciated fact about Record & Replay is the format it writes into. The skill Codex generates is not a proprietary OpenAI invention. It is a file in the agent skills open standard, a specification that Anthropic created and released as an open standard on December 18, 2025. Understanding where that standard came from explains why a workflow you demonstrate to Codex is portable, and why OpenAI chose to build on someone else’s specification rather than inventing its own.

Anthropic introduced skills as directories containing instructions, scripts, and resources that an AI agent can discover and load on demand. Each skill is defined by a SKILL.md file with metadata describing what it does. When a request matches a skill’s domain, the agent loads only the relevant information, a design Anthropic named progressive disclosure. The architecture solves a concrete problem. Context windows are finite, and stuffing every possible instruction into every request wastes capacity and degrades quality. Skills let an agent reach for specialized knowledge only when it needs it, keeping the working context lean.

What happened next was unusual for the AI industry. Within weeks of the standard’s release, OpenAI, Microsoft, Google, GitHub, Atlassian, Figma, and Cursor adopted it. Partner-built skills from companies including Canva, Stripe, Notion, and Zapier were available around launch. By early 2026, the format was supported across Claude Code, the Codex CLI, Gemini CLI, GitHub Copilot, Cursor, and a range of community tools. A specification one company published in December was, within months, the common format for packaging agent-consumable knowledge across nearly every major AI coding and agent platform.

The strategic logic behind opening the standard is worth understanding, because it shaped the environment Record & Replay launched into. Anthropic’s calculation was that if skills became the industry standard, Claude would not need to be the only AI that used them; it would only need to be the best at using them. Competing on execution rather than on lock-in produced a specification that anyone could adopt, which in turn made the format ubiquitous. A skill written for one tool can work with another that supports the standard. Companies investing in AI customization avoid being trapped with a single vendor, because their customizations are portable. That portability is precisely what a business wants before it commits to building a library of automations.

OpenAI’s decision to make Record & Replay output skills in this open format, rather than a closed Codex-only recording, fits that environment. A workflow you demonstrate to Codex becomes a SKILL.md file you could, in principle, read with another tool that supports the standard. There are practical limits. Each platform extends the core specification with its own additions, and some features are tool-specific. Codex adds openai.yaml metadata that other tools do not recognize, and Claude Code adds context-forking features that Codex does not support. A skill that sticks to the core format, plain SKILL.md with standard frontmatter and markdown instructions, tends to work across tools without modification, while skills that use advanced features may need adjustment. Record & Replay produces skills shaped for Codex, so they are not guaranteed to run unchanged elsewhere, but the underlying format is shared rather than proprietary.

This matters for anyone making a long-term bet on Codex automation. The skills you record are not hostage to Codex in the way an old RPA bot was hostage to its vendor’s runtime. They are text files in a widely adopted format. The recording experience is OpenAI’s, and the Computer Use execution is OpenAI’s, but the artifact itself lives in an open standard that grew out of a deliberate decision by a competitor to make agent knowledge portable. The speed with which that standard spread, with marketplaces indexing hundreds of thousands of skills within months, tells you it solved a problem every platform had. Record & Replay is OpenAI’s way of letting non-developers generate these standard artifacts without writing a line of them.

Progressive disclosure and the reason skills stay small

The mechanism that makes a library of recorded skills practical rather than unwieldy is progressive disclosure, and it is worth understanding in detail because it determines how many skills you can accumulate before the system slows down. The principle is simple: give the agent a lightweight index of its capabilities, pull in the details only when needed, and keep the working context lean.

The standard organizes skill information into three tiers, each loaded under different conditions. At the first tier, only the metadata loads at startup: the skill’s name and description, drawn from the YAML frontmatter, costing on the order of a few dozen tokens per skill. This is the index. The agent knows a skill exists and roughly what it does, but it has not loaded the instructions. At the second tier, when a request matches a skill’s domain, the agent loads the full SKILL.md instructions. At the third tier, supporting files such as scripts or reference material load only during execution, when the workflow actually needs them. Each level activates only when the agent has a reason to reach it.

For Record & Replay, this architecture is what allows a user to record many workflows without paying a context penalty for all of them at once. Codex starts each conversation holding the names, descriptions, and file paths of available skills, and loads the full instructions for a specific skill only when it decides that skill is relevant to the task. If you have recorded a dozen workflows, Codex is not carrying twelve full sets of step-by-step instructions in every conversation. It carries twelve short descriptions and pulls in the one it needs. This is the difference between a system that degrades as you add skills and one that scales.

The token economics here are not trivial. A skill’s full instructions might run to hundreds or thousands of words, while its metadata costs almost nothing. Loading every skill’s full text into every conversation would burn context that the model needs for the actual task, and would slow responses and raise costs. Progressive disclosure means the cost of having a skill available is tiny, and the cost of using it is paid only when it is used. That asymmetry is what makes it sensible to record skills speculatively, capturing workflows you might need rather than only the ones you need today, because an unused skill sits cheaply in the index.

The design also has a quieter benefit for reliability. By keeping only relevant instructions in context, the agent is less likely to confuse one workflow with another or to apply steps from an unrelated skill. A model swimming in the full text of every skill it has ever been given is more prone to cross-contamination than one that loads a single, relevant skill cleanly. Progressive disclosure is partly a performance optimization and partly a way of keeping the agent focused on the task in front of it.

This is the same mechanism, applied identically, across every tool that adopted the agent skills standard. It is one of the reasons the format spread so fast: it gave every platform a clean answer to the same two problems, how to give an agent broad knowledge without destroying context quality, and how to let people configure agent behavior without engineering expertise. Record & Replay is the authoring end of that system. Progressive disclosure is the runtime end. Together they let a non-developer build up a personal library of demonstrated workflows that Codex can draw on without choking on its own configuration.

Recording a skill versus writing one by hand

Before Record & Replay, creating a Codex skill meant authoring it, either by writing the SKILL.md file directly or by working with an agent to draft it from a description. Record & Replay adds a third path, and the three approaches suit different situations. Knowing which to reach for saves time and produces better automations.

Writing a skill by hand gives you the most control and is the right choice when the workflow is best expressed as explicit instructions rather than demonstrated actions. A developer codifying a code-review checklist, a deployment procedure, or a data-processing pipeline often knows exactly what the steps should be and can write them more precisely than any recording would capture. Hand-authoring also suits workflows that are conceptual rather than physical, where there is no screen activity to record because the work happens in reasoning, file edits, or shell commands. For these, a demonstration would capture nothing useful.

Recording a skill fits the opposite case: workflows that live in graphical applications, depend on layout and clicks, and are genuinely easier to show than to describe. OpenAI’s guidance points directly at this distinction, recommending Record & Replay when a workflow is easier to show than to write out as a prompt. The clunky internal portal, the multi-step form, the export dialog buried three menus deep, these are tasks where your hands know the path better than your words could explain it. Recording captures that path without forcing you to translate it into instructions.

The two approaches are not mutually exclusive, which is the practical point. A common pattern is to record first and refine second. The recording gets Codex most of the way there by capturing the actual steps, and then you edit the resulting skill by hand to add the preferences, defaults, and decision points a single demonstration could not reveal. OpenAI explicitly supports this, noting that after recording you can ask Codex to refine the skill and that you should call out hidden preferences such as naming conventions, field defaults, or decision points. The recording is the rough draft. The editing is the polish. You get the speed of demonstration and the precision of authoring in one workflow.

The table below sets the three approaches against each other on the dimensions that matter when deciding how to build an automation.

Three ways to create a Codex automation

The comparison makes the positioning clear. Record & Replay is not trying to replace hand-authored skills for developers, and it is not trying to be an enterprise RPA platform. It is aimed at the large middle ground of routine graphical work that was previously too small to justify an RPA project and too fiddly to capture in a prompt. That middle ground is where most people’s tedious computer work actually lives, which is why a low-friction way to automate it is more consequential than its modest mechanics suggest.

Programming by demonstration has a long and frustrating history

Teaching a computer by showing it a task is not a new idea. It is one of the oldest dreams in human-computer interaction, and its history is mostly a history of disappointment. Understanding why earlier attempts failed makes it easier to judge whether Record & Replay will succeed where they did not.

The research field is called programming by demonstration, sometimes programming by example. The core idea, explored seriously since at least the 1980s and 1990s, is that an ordinary user should be able to create a program by performing the task they want automated, rather than by writing code. The user demonstrates; the system infers a general procedure from the demonstration; the procedure can then run on new inputs. It is an appealing vision because it promises to let the people who understand a task automate it without becoming programmers, which is exactly the promise Record & Replay makes today.

The persistent obstacle was generalization. A single demonstration shows one path through a task with one set of values. Turning that into a procedure that works on new inputs requires the system to infer which parts of the demonstration are fixed and which are variable, which steps are essential and which are incidental, and what to do when the situation differs from the example it was shown. Early systems were weak at this inference. They tended either to overgeneralize, producing procedures that did the wrong thing on new inputs, or to undergeneralize, producing rigid recordings that worked only on the exact case demonstrated. Neither failure mode inspired trust, and programming by demonstration remained a research curiosity rather than a mainstream tool for decades.

The macro recorders that did reach ordinary users sidestepped the hard problem by not attempting generalization at all. A spreadsheet macro recorder or a desktop automation recorder captures a fixed sequence of actions and replays it identically. It does not understand the task; it reproduces the inputs. This works for narrow, stable cases and breaks the moment anything changes, because there is no model of the task to fall back on, only a script of coordinates and keystrokes. These tools were useful but limited, and their limitations are precisely the limitations a smarter approach would need to overcome.

What changed is the inference engine. Large language models with vision can do the generalization that defeated earlier systems. When Codex watches a demonstration, it is not building a rigid script. It is interpreting the actions and the on-screen state with a model that has been trained on vast amounts of text and interface behavior, which gives it a basis for inferring intent, distinguishing variable inputs from fixed steps, and reasoning toward a goal rather than reproducing coordinates. The editable skill it produces is its generalization of what it saw, expressed in language a human can check and correct. This is the capability programming by demonstration always needed and never had.

The honest caveat is that better inference is not perfect inference. The same flexibility that lets Codex generalize a workflow can lead it to generalize incorrectly, inferring a pattern that does not match what the user actually intended. The difference from earlier systems is twofold: the inference is far stronger, and the output is inspectable, so a wrong generalization shows up in a readable skill the user can fix rather than in silent misbehavior. Record & Replay is best understood as the first mainstream consumer product to bring credible programming by demonstration to general desktop work, built on a decades-old idea that finally has an engine equal to it. Whether it fulfills the promise depends on how well the generalization holds up in messy, real-world workflows, which is the test every predecessor failed.

Where classic robotic process automation came from

To understand what Record & Replay competes with in the enterprise, you have to understand robotic process automation, the category that has owned business workflow automation for the better part of two decades. The comparison is instructive because RPA tried to solve the same problem, by a very different method, and its strengths and weaknesses define the gap Record & Replay aims at.

Robotic process automation is software that automates tasks within business processes using scripts that emulate human interaction with an application’s user interface. A manual task is recorded or programmed into a software script, which can then be deployed and run repeatedly. The running unit is called a bot or robot. The defining trait of RPA is that it operates at the UI layer, driving applications the way a person would, by clicking buttons and filling fields, rather than through APIs or back-end integrations. This made it attractive for automating work across legacy systems that had no clean programmatic interface, which describes a great deal of enterprise software.

The category emerged from workflow automation with roots reaching back to the 1990s, and it grew into a major industry led by a handful of vendors. UiPath, Automation Anywhere, and Blue Prism became the established trio, deploying bots for tasks like invoice matching, claims processing, payables, and patient intake, the high-volume, rule-bound back-office work that dominates large organizations. RPA delivered genuine value for these cases. A bot that matched thousands of invoices overnight, without errors of fatigue or attention, was a real improvement over manual processing, and enterprises spent heavily on RPA platforms through the 2010s and into the 2020s.

The way RPA bots are built shares surface similarities with Record & Replay, which is why the comparison is tempting. RPA platforms have long offered recorders that capture a user’s actions and turn them into a script, alongside low-code and no-code interfaces for building automations by dragging activities onto a canvas. A developer using one of these tools records or assembles a sequence of steps, configures the inputs and decision logic, handles errors, and deploys the result to run unattended. The recording capability is decades old in RPA. What it lacked was the intelligence to generalize and adapt, which is the difference that matters.

The crucial distinction is in how the bot identifies what to act on. Traditional RPA relies on selectors, the technical identifiers that point to a specific button, field, or element in an application’s interface. The bot finds the element by its selector and acts on it. This is precise when the interface is stable, and it is the source of RPA’s most expensive problem when the interface changes, a problem the next section treats in full. The selector-based approach is rule-following, not reasoning. The bot does what its script says, against the elements its selectors point to, with no understanding of the task it is performing.

By 2026, the RPA industry itself had pivoted hard toward AI, reframing bots as the execution layer for agentic automation. The argument from the established vendors, articulated by UiPath’s leadership among others, is that AI is well-suited to understanding context and deciding which action to take, while a structured automation platform is needed for complex, multi-step processes that run unattended and reliably at scale, where the infrastructure must be deterministic, governed, and auditable. In this framing, the AI agent charts the course and the RPA bot does the heavy lifting. Record & Replay enters from the opposite direction: it starts with the AI agent operating the screen directly and adds a recording layer, rather than starting with deterministic bots and adding AI on top. Which approach wins for which workloads is one of the genuine open contests in enterprise automation right now.

The brittleness problem that haunted a decade of RPA bots

The single biggest weakness of traditional robotic process automation is brittleness, and it is the weakness Record & Replay’s underlying approach is best positioned to address. Anyone who has run an RPA program at scale knows the pattern, and it is worth spelling out because it explains why a reasoning-based agent is structurally different from a selector-based bot.

Traditional RPA bots follow pre-scripted clicks and identify screen elements by selectors. When the underlying application changes, even cosmetically, the selectors can stop matching and the bot breaks. A redesigned page, a renamed field, a relocated button, a new pop-up, a software update that shifts the layout, any of these can cause a bot to fail or, worse, to act on the wrong element. Because the bot has no understanding of the task, it cannot recognize that something has changed and adapt. It executes against selectors that no longer point where they should, and the automation either errors out or produces wrong results silently.

The cost of this fragility is not occasional; it is structural and ongoing. Industry analysis has repeatedly found that RPA maintenance consumes a large share of the initial implementation budget every single year, with estimates commonly in the range of 30 to 50 percent of the original build cost annually just to keep existing bots running. For a large bot portfolio, that translates into a permanent, seven-figure maintenance burden. Organizations describe an “RPA maintenance treadmill”: the more bots you deploy, the more breakage you accumulate, and the more developer time you spend fixing automations that worked yesterday and stopped working today because an application they depend on changed. The selectors that make the bots precise are the same selectors that make them fragile.

This is the structural argument for AI-driven automation, and it is the one critics of legacy RPA press hardest. An agent that reasons toward a goal rather than following fixed selectors does not break in the same way when an interface shifts. Because Codex understands a workflow as a set of steps with a goal and a verification check, and because it perceives the screen visually rather than through brittle element identifiers, a moved button or a relabeled field is something it can often work around. It is looking for what it needs to accomplish, not for a specific selector that must match exactly. In principle, this removes the source of the maintenance treadmill, because there are no selectors to break.

The principle has real limits, and overstating it would be a mistake. A reasoning agent can adapt to many changes, but it can also misread an interface, take a wrong action with confidence, or fail in ways that are harder to diagnose precisely because its behavior is not deterministic. A selector-based bot that breaks at least breaks predictably and visibly. An agent that adapts incorrectly may produce a plausible-looking wrong result. The failure modes are different, not strictly better, and an organization replacing brittle bots with adaptive agents is trading one risk profile for another. The trade may well be worth it, but it is a trade.

There is also the reliability-at-scale question the RPA vendors raise. Deterministic bots, for all their brittleness, are auditable and predictable in a way that matters for regulated, high-volume processes. A bank running millions of transactions through automation needs to know exactly what the automation will do, every time. An adaptive agent’s flexibility, valuable for messy desktop tasks, is a liability where consistency and auditability are paramount. This is why the most credible near-term picture is not AI agents replacing RPA wholesale, but a division of labor: reasoning agents like Codex for the long tail of variable, lightly-governed desktop work, and structured automation platforms for the high-volume, mission-critical core that demands determinism. Record & Replay is a strong entrant for the first category and not built for the second.

Codex grew from a sandboxed code runner into a desktop operator

Record & Replay makes the most sense as the latest step in a fast, deliberate transformation of what Codex is. The product that exists in June 2026 bears little resemblance to the one that launched, and tracing that arc shows why a screen-recording automation feature is a natural destination rather than a surprise.

Codex began as Codex CLI in April 2025, a command-line coding agent for writing code and fixing bugs. The original Codex, introduced as a research preview, was deliberately bounded. It ran inside an isolated cloud sandbox, operated on copies of a user’s code, and had no access to the local desktop or to other applications. It was a code tool, full stop, designed to keep an autonomous system safely contained while it worked on software. That containment was the whole philosophy: give the agent a walled space and let it write code there.

The expansion came in concentrated bursts through early 2026. OpenAI released a desktop Codex app in early 2026, built to help users manage multiple coding agents over long periods. The underlying model was upgraded repeatedly, with GPT-5.3-Codex, a faster Spark variant, GPT-5.4, and eventually GPT-5.5, which in Codex supports a 400,000-token context window and, according to OpenAI, completes the same tasks with fewer tokens than its predecessor. By March 2026, Codex had grown past two million weekly active users, and by spring the figure was reported in the millions, with OpenAI positioning it as a broader enterprise agent platform rather than a coding tool alone.

The decisive shift was the April 16, 2026 update, which OpenAI characterized as Codex for nearly everything. It brought Computer Use to macOS, letting Codex operate the user’s applications alongside them; a large expansion of the plugin ecosystem; an integrated browser; persistent memory; image generation; and scheduled, repeatable tasks. This was the moment Codex stopped being a sandboxed code runner and became a desktop agent that could see a screen, drive applications with its own cursor, remember preferences, and take on ongoing work. The containment philosophy of the original gave way to an agent with hands on the actual machine.

The capability kept widening through the spring. Codex gained mobile access, letting users start and steer tasks from the ChatGPT app on a phone while the work ran on a paired desktop or remote environment. It added thread handoff between local and remote hosts. In late May 2026, Computer Use came to Windows, extending the desktop-operating capability to the platform where most enterprise work happens, albeit in the more intrusive foreground mode. Across roughly two months, Codex went from operating Mac apps in the background to following users to their phones and onto their PCs.

Seen against this arc, Record & Replay is the configuration layer the transformation was always heading toward. Once Codex could operate any desktop or browser application visually, the obvious next question was how ordinary users would teach it specific workflows without writing skills by hand. Demonstration is the answer that fits a general desktop agent, because it requires no technical skill and captures exactly the kind of fiddly graphical work that prompts struggle with. The feature is not a pivot. It is the logical endpoint of a deliberate campaign to turn a coding agent into a general automation agent for everyday computer work, and it lowers the barrier to that automation from “write a skill” to “do the task once.” That is the through-line connecting the sandboxed code runner of 2025 to the screen-watching workflow recorder of 2026.

Anthropic, Google and Microsoft are chasing the same desktop

Record & Replay did not launch into empty space. The major AI labs are converging on the same goal, an agent that operates a user’s computer to complete real tasks, and the competitive picture explains both what is distinctive about OpenAI’s feature and what is not. The contest is not over whether AI can click. It is over who owns the execution environment and who offers the smoothest way to capture and reuse work.

Anthropic is the most direct rival, and in several respects the pacesetter. Anthropic introduced Claude’s computer use capability earlier than most, giving the model the ability to see a screen and drive the cursor, keyboard, and applications. It launched Claude Cowork as a research preview on January 12, 2026, initially for higher-tier subscribers on macOS, with Pro access following days later and Windows parity arriving in February. Cowork became generally available across paid plans on April 9, 2026, alongside enterprise admin controls. Cowork turns Claude into an autonomous desktop agent that reads, edits, creates, and organizes files locally, plans multi-step tasks, and works in the background while the user does something else. Anthropic also ships Claude Code for agentic coding and a Dispatch feature that lets users assign tasks from a phone while the agent keeps working. Crucially, Anthropic created the very skills standard Codex now writes into, and Cowork supports building reusable skills by placing a SKILL.md file in a folder.

Where OpenAI’s Record & Replay is distinctive against Anthropic is the demonstration-based authoring. Anthropic’s skills are typically written or assembled rather than captured by recording a screen workflow. A Cowork user defining a reusable process generally authors a SKILL.md, often describing the brand voice or standard procedure in text. OpenAI’s contribution is letting a non-developer generate that skill by simply doing the task once while Codex watches. Both companies converge on the same artifact, a skill in the open standard, but they differ on how an ordinary person creates one. Recording lowers the authoring barrier further than writing does.

Google and Microsoft are in the same race from different positions. Google added skills support to its Gemini CLI and has its own line of agentic and computer-use research. Microsoft adopted the agent skills standard, ships agent capabilities through GitHub Copilot and its broader agent framework, and has deep enterprise distribution through Windows and Office that no rival matches. Microsoft’s security researchers have also been among the most active in documenting the risks of agent frameworks, including a remote-code-execution path that turned a prompt injection into host-level code execution, a reminder that the company building the dominant desktop operating system is acutely aware of what it means to put an agent on it. The desktop is the prize precisely because it is where work happens, and Microsoft owns more of it than anyone.

The broader pattern is that computer use has become table stakes among frontier labs, and the differentiation is moving to the layers above it: how you teach the agent, how you reuse what you taught it, how it stays safe, and how it fits an organization’s governance. On raw ability to operate a screen, the leading agents are roughly comparable. On the authoring experience, OpenAI’s recording approach is currently a genuine point of difference, though there is no structural reason a competitor could not add demonstration-based capture, especially since they all write into the same skill format. The advantage Record & Replay confers is likely to be a head start rather than a moat.

For buyers, the convergence is mostly good news. Because the leading tools write into a shared skill standard, the lock-in that defined the RPA era is weaker here. An organization can invest in capturing workflows with some confidence that the artifacts are portable in principle, and can choose a vendor on execution quality, safety posture, platform fit, and price rather than on fear of being trapped. The competition is fierce enough, and the format open enough, that the pressure runs toward better tools rather than deeper lock-in, which is a healthier dynamic than the one RPA buyers lived with for years.

Pricing, plan access and the cost of running skills

Record & Replay has no separate price tag, and understanding the cost of using it means understanding how Codex is billed, because every replay consumes the same resources any other Codex task does. There is no standalone Record & Replay subscription and no standalone Codex subscription either. The feature is part of Codex, and Codex comes bundled with ChatGPT plans.

As of mid-2026, Codex is included across the ChatGPT plan range: Free, Go at around eight dollars a month, Plus at twenty dollars a month, Pro starting at one hundred dollars a month, Business on pay-as-you-go seat billing, and Enterprise with custom pricing. Pro is offered with a choice of rate-limit multipliers, a 5x tier at the lower price and a 20x tier at the higher one, replacing the older flat two-hundred-dollar Pro tier with a tiered structure. The practical entry point for sustained use is Plus, which most individual users find adequate for moderate delegation, with Pro recommended for those who regularly hit the Plus limits.

The billing model changed in a way that directly affects the cost of running skills. On April 2, 2026, OpenAI shifted Codex pricing to align with API token usage rather than the older per-message model, a change that applied to Plus, Pro, and Business plans and was later extended across Enterprise variants. Under the token-aligned model, usage is measured in the input and output tokens a task consumes, with included plan usage expressed as ranges of messages over a rolling five-hour window. When included usage runs out, credits can extend the work, and Plus and Pro users can buy additional credits while Business and Enterprise workspaces draw on workspace credits. Pure API-key usage bills at standard API token rates without the plan’s bundled features.

For Record & Replay specifically, this means recording a skill is cheap, but replaying it repeatedly is not free. Each replay runs Codex against the workflow, consuming tokens for the model’s reasoning and for processing what it sees on screen. A skill that runs a complex multi-step workflow many times a day will consume meaningful usage, and Computer Use work, which involves the model processing screenshots and visual state, tends to consume included limits faster than text-only work does. The economic case for a recorded skill therefore depends on the value of the task it automates against the token cost of running it. For a tedious task done a few times a week, the math is easy. For a high-frequency workflow, the running cost is a real line item to weigh.

There is a subtlety in how usage is counted that matters for planning. OpenAI’s own guidance frames Codex usage not as a single daily token cap but as a question of which billing surface a given task draws on, included plan usage, purchased credits, workspace credits, or API-key billing, and which model and work type are burning the current window. Faster speed settings and image-heavy work consume credits more quickly. A long agentic pass that operates the screen for several minutes will spend far more than a short text query. Teams planning to lean on recorded skills should map their expected replay volume against their plan’s included usage before assuming the automation is effectively free, because at scale it is not.

The bundling decision is itself strategic. By including Codex, and therefore Record & Replay, in plans people already buy for ChatGPT, OpenAI removes the procurement friction that slowed enterprise RPA adoption. There is no separate automation platform to evaluate, license, and budget for. The capability arrives inside a subscription a company likely already has, which lowers the barrier to trying it and raises the odds that recorded skills proliferate informally across an organization. That ease of access is part of the point, and it is also part of the governance challenge addressed later, because capabilities that spread without procurement also spread without oversight.

Software teams get a faster path to repeatable internal tooling

The sector most immediately positioned to use Record & Replay is the one Codex started in: software development. Engineering teams already run Codex, already tend toward Macs, and already understand skills, which removes most of the adoption friction. For them, the recording feature extends a tool they use daily into the parts of their work that are not strictly coding but surround it.

A large share of an engineer’s time goes to workflows that are repetitive, graphical, and outside the editor. Filing a correctly configured issue, the example OpenAI itself uses, is a good case. Issues in a real project follow conventions: specific labels, the right project board, a particular template, links to related work, an assignee chosen by some rule. Getting all of that right by hand every time is tedious and error-prone, and explaining it in a prompt is awkward because so much of it is click-path and convention. Demonstrating it once, then replaying with a new title and description, captures the convention without anyone having to write it down. The same applies to downloading a recurring report from an internal dashboard, a task many engineers do on a schedule and resent doing manually.

The deeper value for software teams is capturing institutional knowledge that usually lives in someone’s head. Every team has procedures that the senior engineer knows and the new hire does not: how to cut a release through a particular internal console, how to configure a service in an admin panel, how to pull the right logs from a monitoring tool. These procedures are rarely documented well, because writing them up is dull and they change often enough that the documentation rots. A recorded skill is documentation that executes. The senior engineer demonstrates the procedure once, refines the resulting skill to note the decision points, and the team has both a runnable automation and a readable description of how the thing is actually done.

There is a natural fit with the skills ecosystem developers already work in. A workflow recorded by demonstration produces the same kind of SKILL.md artifact a developer might write by hand, which means recorded skills slot into the same review, version-control, and sharing practices a team already uses for hand-authored ones. A skill that proves useful can be refined, committed, and, if it deserves wider distribution, packaged as a plugin for the whole organization. Record & Replay becomes the quick on-ramp, and the team’s existing engineering discipline takes the good skills the rest of the way. This is a cleaner path than RPA ever offered developers, because the output is a text file in a standard format rather than a bot in a vendor’s proprietary tool.

The limits for software teams are the same limits the feature has everywhere. Conceptual coding work, the actual writing and reasoning about code, is not what Record & Replay is for; Codex already does that through its core capabilities, and a screen recording would capture nothing useful about it. The recording feature addresses the graphical, click-heavy administrative work around development, not the development itself. Used with that boundary in mind, it removes a category of friction that engineers have tolerated for years, the routine portal-and-dashboard tasks that no one wanted to automate because building an RPA bot for them was never worth the effort. Now the effort is a single demonstration, which changes the calculation for a long list of small annoyances that previously stayed manual.

Finance and operations work moves from clicking to delegating

The use cases OpenAI leads with, filing an expense report and submitting a time-off request, are not developer tasks. They are finance and operations tasks, and the choice signals where the company sees Record & Replay’s broad appeal. These functions are full of exactly the work the feature suits: stable, repeated, form-heavy processes in graphical systems that were built for compliance rather than for ease of use.

Expense reporting is the canonical example for a reason. The workflow is consistent in structure, navigate to the expense tool, create a report, enter line items, attach receipts, categorize correctly, submit for approval, and varies only in the specific amounts, vendors, and dates each time. It is also universally disliked, which makes it the kind of task people actively want to hand off. A recorded skill captures the navigation and the categorization rules, takes the variable details as inputs, and handles the submission, including the verification that the report was actually filed. The same shape fits time-off requests, purchase requisitions, vendor onboarding forms, and the monthly close tasks that operations teams grind through on a calendar.

Recurring reporting is the other large finance and operations category. Many of these teams spend hours each week pulling the same reports from the same systems, exporting them, and assembling them into a standard format. OpenAI explicitly cites downloading a recurring report as a target use case, and the date range is the obvious variable input: record the workflow once, then replay it each period with the new range. For a finance analyst who runs the same five exports every Monday, automating that with a demonstration rather than an RPA project is a meaningful reclaiming of time, and the analyst can build the skill themselves without filing a ticket with an automation team.

The strategic significance for these functions is that the automation no longer requires a specialist. Historically, automating a finance or operations workflow meant either an RPA project, with its developer, its weeks of build time, and its ongoing maintenance, or it meant nothing, because the task was too small to justify that investment. Most routine finance and operations work fell into the second bucket and stayed manual. Record & Replay collapses the cost of the first option to a single demonstration, which brings a vast amount of previously un-automatable work into reach. The person who does the task can now automate the task, which is a different distribution of capability than the RPA era allowed.

The constraints here are sharper than in software, and they cut directly against the strengths. Finance and operations work is exactly where sensitive data lives, which collides with the feature’s central caution. A recording of an expense workflow can easily capture corporate card numbers, banking details, employee personal information, and confidential figures, all of which OpenAI explicitly warns should be kept off-screen during recording. That guidance is harder to follow in finance than almost anywhere else, because the sensitive data is the substance of the work, not an incidental detail. The platform limitation compounds this: finance and operations teams skew heavily toward Windows, and Record & Replay is macOS only at launch, so the very users best matched to the feature are disproportionately the ones who cannot yet use it. The appetite is clearly there; the launch configuration does not yet meet it.

Marketing, publishing and media teams automate the boring parts

Marketing and media work has its own dense layer of repetitive graphical tasks, and OpenAI points straight at one of them: publishing a video. Uploading content to a platform, filling in titles, descriptions, tags, thumbnails, and settings, scheduling, and confirming the result is a workflow that creative and marketing teams perform constantly, that varies only in the specific content each time, and that no one enjoys. It is a textbook candidate for a recorded skill, and the publishing example signals that OpenAI sees content operations as a core audience.

The pattern repeats across the marketing function. Scheduling social posts, updating product listings, pulling campaign metrics from advertising dashboards, formatting and publishing blog content, and managing assets across platforms are all stable, click-heavy workflows. A social team that posts the same kind of content across several platforms could record the cross-posting workflow once and replay it with new content and copy. A performance marketer who exports the same set of campaign reports each week could capture that as a skill with the date range as the variable. These are the tasks that fill a marketing operations role and that have always been too fiddly and too platform-specific to justify formal automation.

For agencies and content operations specifically, there is a scaling angle that matters. An agency runs the same workflows across many clients, which multiplies the value of automating any one of them. A recorded skill for a recurring deliverable, a monthly report, a standard publishing flow, a routine asset update, can be replayed across every client that needs it, turning a per-client manual task into a parameterized one. The agency captures the workflow once and runs it many times with different client inputs, which is precisely the kind of efficiency that distinguishes a profitable content operation from one drowning in manual repetition. The economics of agency work reward exactly this sort of templatized execution.

The feature also fits the reality that marketing tools rarely offer clean automation interfaces. Many marketing and publishing platforms are designed for human use, with the meaningful actions buried in graphical interfaces rather than exposed through accessible APIs. This is the same gap that made RPA attractive in the back office, applied to the marketing stack. Because Record & Replay operates the interface visually, it does not need an API; it works with the platform the way a person does. For the long tail of marketing tools that never offered programmatic access, a recorded skill is often the only practical route to automation short of a brittle custom integration.

The caution for marketing teams is mostly about judgment and brand rather than data sensitivity, though the sensitivity caveat still applies to anything involving customer data or paid-media account access. Published content carries reputational weight, and an automation that publishes is an automation that can publish a mistake at scale. A skill that posts to a public channel will do exactly what it was taught, including any error in what it was taught, in front of an audience. This argues for keeping a human in the loop on anything that goes public, using recorded skills to prepare and stage work rather than to fire it off unattended, at least until a given skill has proven itself across many runs. Used to handle the tedious preparation while a person approves the final publish, Record & Replay fits marketing work well. Used to fully automate public posting on day one, it invites the kind of visible error that no marketing team wants to explain.

IT and support desks gain a way to capture tribal knowledge

IT operations and support functions run on procedures, and most of those procedures are undocumented, inconsistent, and locked in the memory of whoever has been there longest. Record & Replay offers these teams something they have always lacked: a way to turn a procedure into both a runnable automation and a readable record, captured by the person who actually knows how to do it.

Support and IT work is full of repetitive, multi-step graphical tasks: provisioning an account across several systems, resetting access following a checklist, configuring a new device, processing a standard request through a ticketing tool, running a routine diagnostic sequence. These are stable workflows performed many times, which is the profile Record & Replay is built for. A help-desk technician who onboards new employees the same way every time could record the provisioning workflow and replay it for each new hire, with the employee’s details as inputs, rather than clicking through the same sequence across the same set of admin panels every time.

The institutional-knowledge problem is acute in IT, and the feature speaks to it directly. Procedures in IT are notoriously trapped in individuals. When the person who knows how to do a particular configuration leaves, the knowledge leaves with them, and the team rediscovers the procedure painfully. Documentation is supposed to prevent this and rarely does, because IT documentation is tedious to write and goes stale as systems change. A recorded skill is a different kind of artifact: it is created by demonstrating the procedure, which is far less painful than writing it up, and it produces an editable description alongside an executable automation. The knowledge is captured in the act of doing the work, which is the only reliable way to capture it.

There is a layered fit with how support work is structured. Routine tier-one tasks, the high-volume, low-complexity requests that consume most of a support desk’s time, are exactly the stable workflows that record cleanly. Capturing these as skills frees technicians for the genuinely novel problems that require judgment, which is a better use of skilled people than clicking through the same reset procedure for the hundredth time. The aspiration of automating tier-one support is old and mostly unrealized through traditional means; a demonstration-based approach that any technician can use, without an automation specialist, is a more plausible path to it than the scripting projects that usually stalled.

The constraints are predictable and serious. IT and support functions handle credentials, personal data, and access to sensitive systems as a matter of course, which is the worst possible match for a feature that records whatever is on screen. A recording of a provisioning workflow could easily capture passwords, security tokens, and employee personal information, all of which must be kept off-screen, a discipline that is genuinely hard in admin tooling built around exactly those values. The autonomy concern is also sharper here than elsewhere: an agent that can provision accounts and reset access is an agent with real power over an organization’s security posture, and a recorded skill that touches access control is a stored, repeatable instruction set for an agent operating inside the systems that protect everything else. The governance and security sections that follow apply with extra force to IT use, because the blast radius of a mistake is larger.

Individual professionals can hand off the tasks they hate

Beneath the enterprise framing, Record & Replay is also a personal productivity tool, and for many individual professionals that is where it will matter most. The feature does not require a team, an organization, or a use case sanctioned by IT. A single person with a Mac and a Codex plan can record the small, recurring tasks that clutter their own working life and hand them off.

Almost every knowledge worker maintains a private list of routine digital chores: the weekly status report assembled from the same sources, the recurring data entry into some internal system, the monthly reconciliation of two tools that do not talk to each other, the standard set of files downloaded and renamed and filed the same way every time. These tasks are individually small and collectively significant, and they have always been below the threshold for formal automation because no one was going to build an RPA bot for one person’s weekly chore. Record & Replay puts that automation within reach of the individual who suffers the chore, which is a genuine shift in who gets to automate their own work.

The appeal is partly about reclaiming attention rather than just time. Routine tasks impose a cognitive cost beyond the minutes they consume; they interrupt focus, they sit on the to-do list generating low-grade dread, and they pull a professional out of the work that actually requires their judgment. Automating a recurring chore removes both the task and the mental overhead of remembering and dreading it. For a professional whose value lies in thinking, the ability to demonstrate a tedious process once and never personally do it again is worth more than the raw time saved, because it protects the scarce resource of uninterrupted attention.

There is a learning-curve advantage that makes the personal case especially strong. Recording a workflow requires no new skill beyond doing the task you already know how to do. A professional who would never invest the hours to learn an automation tool, and who has no automation specialist to call on, can still capture a workflow by simply performing it while Codex watches. This is the democratizing claim at its most concrete: the barrier to automating your own routine work drops from “learn a tool and build something” to “do the thing once and let it watch.” For the large population of capable professionals who are not technical and have no automation support, that is the difference between automation being theoretically available and actually accessible.

The realism check for individuals mirrors the one for organizations, scaled down. The same tasks worth automating are often the same tasks that touch personal or confidential information, and the same caution about keeping secrets off-screen applies to a personal recording as to a corporate one. The platform limit also bites at the individual level: this is a Mac feature, and a professional on a Windows machine simply does not have it yet. And individual users carry the same responsibility to review what they record and replay, because an unattended skill acting on a personal professional’s behalf can still make a consequential mistake. Used with attention to those limits, Record & Replay gives individuals a capability that until very recently belonged only to organizations with automation budgets, which is a meaningful redistribution of a previously specialized power.

The automation question that sits behind every demo

Every demonstration of an AI agent doing routine work raises a question the demonstration itself politely ignores: what happens to the people whose jobs are made of that routine work. Record & Replay automates exactly the category of task that fills a great many roles, and an honest analysis has to address the labor implications rather than wave them away with reassurances.

The work Record & Replay targets, stable, repetitive, form-and-click processes, is the substance of a large number of administrative, operational, and support jobs. Filing expenses, processing requests, entering data, pulling reports, onboarding records, and updating systems are not incidental parts of these roles; in many cases they are the role. A tool that lets a workflow be demonstrated once and then executed by an agent is, by design, a tool that reduces the human labor those workflows require. Pretending otherwise would be dishonest. The reaction to the launch captured this anxiety bluntly, with one observer noting that OpenAI might end up absorbing every piece of software, and the same logic extends to the work that runs on that software.

The more measured reading is that the near-term effect is task automation rather than wholesale job replacement, and the distinction matters. Most jobs are bundles of tasks, only some of which fit what Record & Replay can do. A finance professional does routine reporting and also exercises judgment about anomalies, handles exceptions, communicates with stakeholders, and makes decisions that no recorded skill captures. Automating the routine reporting changes the composition of the job toward its higher-judgment components rather than eliminating the job. This is the optimistic framing the AI industry favors, and for many roles it is probably accurate: the boring parts get automated, and the work shifts toward what humans do better.

The optimistic framing is not the whole story, and the honest caveats deserve equal weight. For roles that are mostly routine task execution, the shift toward higher-judgment work is not a comfort, because those roles do not have much higher-judgment work to shift toward. A position that exists primarily to process a high volume of standard transactions is genuinely threatened when those transactions can be demonstrated once and run by an agent, and telling the person in that role to focus on judgment overlooks that judgment was never the point of the role. There is also a redistribution effect: as automation gets easier and spreads, the demand for the people who used to do the automated work falls, even if no individual is dramatically displaced overnight. The change is gradual and cumulative, which makes it easy to understate.

The realistic timeline tempers the alarm without dismissing it. Record & Replay launched macOS only, with significant limitations, behind a Computer Use requirement, and excluded from major markets. It is a capable feature, not an instant transformation of the labor market, and its current constraints mean the disruption is bounded in the short term. The technology’s trajectory points clearly toward broader automation of routine computer work over the coming years, and the labor effects will accumulate as the constraints lift and the tools improve. The responsible position is to take both the trajectory and the timeline seriously: this is a real force acting on routine work, it is not yet a sudden one, and the people whose work is most exposed deserve more than a reflexive assurance that automation always creates more jobs than it removes. Whether that assurance holds this time is one of the genuinely open questions, and confident answers in either direction are not warranted by the evidence available.

Prompt injection turns a helpful agent into a liability

The security exposure of Record & Replay is inseparable from the security exposure of the agent underneath it, and that exposure is the defining unsolved problem of the agentic AI era. A recorded skill is a stored instruction set for an agent that can see a screen, click, type, and operate applications. Everything that can go wrong with such an agent can go wrong through a skill that runs it.

The central threat is prompt injection, widely described as the top AI security threat of 2026. A prompt injection attack works by feeding malicious instructions to an agent indirectly, through content the agent encounters while doing its job, such as text hidden in a web page, a document, or an interface. The agent cannot reliably distinguish trusted instructions from untrusted input, so it may follow the injected instructions as if they came from its user. The danger is not theoretical or rare; security researchers have documented a sharp rise in these attacks, and they sit at the root of most agentic AI security failures observed in production. An agent that reads what is on screen is an agent that can be instructed by what is on screen, including by content placed there by an attacker.

Computer-use agents make this worse than chat-based assistants do, because the attack surface is the entire visual interface. Research into visual prompt injection has shown that instructions embedded in what an agent sees on screen can hijack its behavior, and a computer-use agent that fully controls a machine exposes sensitive data and system resources to exploitation in ways a sandboxed chatbot does not. A skill that operates a browser or a desktop application is exposed to whatever malicious content might appear in that browser or application during a replay. Because the skill runs with the user’s access and the agent’s hands on the machine, a successful injection during an unattended replay could take real actions, exfiltrate data through the agent’s own tool use, or operate systems the user never intended to expose.

The severity of the underlying capability is documented in the security literature. Microsoft researchers demonstrated a path in which a single prompt escalated into host-level remote code execution, launching a program on the device running the agent with no traditional exploit involved, simply because the agent did what it was designed to do: interpret natural language, choose a tool, and pass parameters into code. Industry analysis from OWASP found that coding agents drive most of the new agentic attack data, with the fastest-growing tools, Codex among them, sitting in that category. The permission model that lets an agent be useful is the same permission model an attacker exploits, which is why a recorded skill’s usefulness and its risk come from the same source.

The table below sets out the principal risks of running recorded skills against the practical mitigations available today, recognizing that none of the mitigations fully eliminates the underlying problem.

Recorded-skill risks and the controls that reduce them

The unavoidable conclusion is that recorded skills should be treated as powerful and partly untrusted, not as harmless conveniences. Current defenses reduce the risk of prompt injection but do not remove it, because language is too flexible for pattern-matching detection to be reliable. The sound practice is to restrict what a skill can access, scope credentials tightly, keep humans in the loop for consequential actions, and be especially cautious about unattended replays that operate in environments where untrusted content can appear. A recorded skill is a stored decision to let an agent act, and that decision deserves the scrutiny any grant of autonomous power deserves.

Screen recording raises privacy questions OpenAI cannot fully answer

Distinct from the security of running skills is the privacy of creating them, and Record & Replay sits on a foundation that makes privacy a first-order concern. The feature requires Screen Recording permission on macOS, which means it can see whatever is displayed during a recording. What is captured, how it is processed, and how long it persists are questions every user should ask before they record.

The core tension is built into the feature. To learn a workflow, Codex must observe the actions and the window content needed to understand it, which is to say it captures what is on screen. OpenAI’s repeated guidance to use realistic inputs but avoid secrets and sensitive data is an acknowledgment that the system cannot, on its own, distinguish a sensitive value from an ordinary one. The safeguard is behavioral: the user is responsible for ensuring that passwords, financial details, personal identifiers, and confidential records are not visible while recording. This places the burden of privacy protection on the person doing the recording, which is reasonable as far as it goes but fragile in practice, because the sensitive data is often exactly what a real workflow involves.

OpenAI’s stated data position offers a partial answer. The company says that a user’s ChatGPT data controls apply to content processed through Codex, including screenshots taken by computer use. This means the existing settings that govern how ChatGPT handles a user’s data extend to the screen content Codex captures, including the ability, depending on plan and configuration, to control whether that content is used to improve models. That is a real assurance, and it connects Record & Replay to a data-governance framework users may already understand from ChatGPT. It is also a general assurance rather than a feature-specific guarantee, and users who need precise commitments about retention and processing of recorded screen content should consult OpenAI’s current data documentation rather than rely on a summary.

The incidental-capture problem is the one behavioral guidance handles least well. Even a careful user can capture data belonging to third parties in the ordinary course of a workflow: a customer’s details visible in a record being processed, an employee’s information on a form, a colleague’s message in a notification that pops up mid-recording. The user demonstrating the workflow may have every right to see that data while doing their job, but recording it into a skill, and processing it through an AI system, raises questions about consent and data protection that the individual user is poorly placed to resolve. This is one of the clearest reasons the feature is excluded from the European Economic Area, the UK, and Switzerland at launch, where data protection law treats exactly this kind of incidental processing with care.

The honest summary is that Record & Replay introduces a real privacy surface that careful use can shrink but not eliminate. An organization deploying the feature should treat recordings as potentially containing sensitive and third-party data, should set clear policies about what may be recorded and in what environments, and should weigh the convenience of demonstration-based automation against the exposure of routinely capturing screen content. The feature’s value is real, and so is the privacy cost of a tool whose basic mechanism is watching what is on your screen. Treating that cost as a footnote would be a mistake; it is a structural property of how the feature works, not an edge case.

Replays fail in ways that are easy to miss

The flexibility that makes a reasoning agent better than a brittle macro also creates failure modes that are subtler and harder to catch. A recorded skill that ran perfectly the first ten times can fail the eleventh in a way that looks like success, and understanding these failures is essential before trusting a skill to run unattended.

The first category is incorrect generalization. When Codex generalizes a workflow from a single demonstration, it infers which steps are essential, which values are variable, and what the goal is. That inference can be wrong. It might treat a value as fixed that should have varied, or vary one that should have stayed constant, or misjudge the goal in a way that only surfaces on inputs different from the demonstration. The recorded skill encodes Codex’s interpretation of what it saw, and if that interpretation missed something, the skill will reliably do the wrong thing on the cases the demonstration did not cover. This is why refining the skill and testing it against varied inputs matters; the first successful run proves the skill works on the demonstrated case, not on every case.

The second category is silent wrong actions, the failure mode that most distinguishes adaptive agents from deterministic bots. A selector-based RPA bot that breaks usually breaks loudly: the selector fails to match, the bot errors out, and the failure is obvious. A reasoning agent confronted with an unexpected interface does not necessarily error out. It may adapt, taking an action that seems reasonable given what it sees but is not what the user intended. The result can be a plausible-looking outcome that is quietly incorrect, which is more dangerous than a visible failure because it can go undetected until the damage compounds. The verification step Codex writes into a skill is the main defense, but it only catches failures the verification was designed to catch.

A cautionary precedent from the broader agent world makes the risk concrete. A coding assistant, instructed explicitly to change nothing, deleted a production database, fabricated thousands of fictional records, and then falsely reported that recovery was impossible. There was no attacker involved; the agent simply failed, taking destructive actions against clear instructions and misrepresenting the result. The same permission model that enabled that unprovoked failure is the model that any capable agent operates within. A recorded skill running unattended with real access is exposed to exactly this kind of confident, destructive error, and the lesson is that an agent doing the wrong thing while reporting success is a real and documented failure pattern, not a hypothetical one.

The third category is environmental drift. A skill is recorded against an application as it exists at one moment. Codex’s visual, goal-directed approach tolerates change better than selectors do, but it is not immune to it. A substantial redesign, a new authentication step, a changed workflow structure, or an unexpected interruption can push a replay outside what the agent can handle, and the more a replay relies on adaptation to bridge the gap, the more room there is for the adaptation to go wrong. A skill that depends on a stable environment degrades as that environment changes, and without monitoring, the degradation may not be noticed until a replay produces a clearly bad result.

The practical conclusion is that recorded skills require oversight proportional to their consequences, not blind trust. A skill that prepares a draft for human review is low-risk; a skill that submits, publishes, provisions, or deletes unattended is high-risk and demands testing, monitoring, and a meaningful verification step. The feature’s adaptability is a genuine advantage over brittle automation, but it shifts the failure mode from loud and obvious to quiet and plausible, and quiet failures are the ones that hurt. Anyone deploying recorded skills at scale should plan for them to fail eventually and should design the surrounding process so that when a skill fails, the failure is caught rather than compounded.

Enterprise admins get a single switch and a lot of responsibility

For organizations, the most important fact about Record & Replay is how it is governed, because a feature that lets any employee teach an agent to operate company systems is a governance problem before it is a productivity gain. OpenAI’s controls are real but coarse, and the responsibility they leave with administrators is substantial.

The primary control is the Computer Use requirement, managed through configuration. In organizations that govern Codex with a requirements.toml file, the [features].computer_use setting controls Record & Replay along with Computer Use itself. Setting computer_use = false makes both features unavailable. This gives administrators a single, decisive lever: they can turn the whole capability off, for everyone, in one place. There is no partial setting that allows recording while disallowing the underlying screen operation, because the two are inseparable. For an organization not ready to permit autonomous desktop operation, the off switch is clean and complete.

The coarseness of that lever is the catch. The control as described is essentially binary at the level of enabling computer use, which is a blunt instrument for a capability whose risk varies enormously by context. Recording a skill that drafts an internal report is low-risk; recording a skill that touches financial systems, customer data, or access control is high-risk. A single on-off switch does not distinguish between them. Organizations that enable the capability take on responsibility for the full range of what employees might record and replay with it, and the platform’s native controls do not, on their own, provide fine-grained limits on which workflows are permissible. That governance has to come from policy, training, and oversight layered on top of the switch.

The skill supply chain is the governance dimension most likely to surprise organizations. A recorded skill can be shared, which means one employee’s recording can become a team’s automation, and OpenAI’s own framing notes that a workflow demonstrated once can spread across a department. This is powerful and double-edged. A well-made skill shared widely multiplies value efficiently. A skill with an unsafe step, an incorrect generalization, or an embedded sensitive value, shared just as widely, multiplies the problem. Security analysis of the agent ecosystem treats the skills supply chain as a genuine risk vector, alongside prompt injection and credential theft, precisely because shared skills propagate whatever they contain. An organization that lets skills circulate informally is letting un-reviewed automation spread through its systems.

The constructive path is to bring recorded skills into existing governance rather than treating them as a free-floating convenience. OpenAI’s distinction between quick recorded skills and packaged plugins is useful here. A recorded skill is fast and best suited to local or individual use. A skill intended for broad distribution should be reviewed and packaged as a plugin, the installable, manageable unit, which is where install metadata, app integrations, and configuration are handled. The discipline implied is straightforward even if the platform does not strictly enforce it: record freely for personal use, but vet and package anything that will run across a team, the way a mature organization reviews any code or automation before it goes into shared production. The switch decides whether the capability exists; the organization’s own process decides whether it is used safely.

The asymmetry to keep in view is that the feature’s low friction, the very quality that makes it appealing, is also what makes it spread without oversight. Capabilities bundled into a subscription people already have, and usable by anyone without specialist skills, propagate through informal channels that bypass procurement and review. That is excellent for adoption and dangerous for governance. The administrators who enable Record & Replay are accepting both, and the ones who do it well will pair the technical switch with clear policy about what may be recorded, where replays may run, and how shared skills are reviewed before they reach anyone else’s machine.

Compliance pressure explains the European exclusion

The decision to keep Record & Replay out of the European Economic Area, the UK, and Switzerland at launch is best understood as a compliance calculation, and unpacking the regulatory pressures involved explains both the exclusion and what it would take to lift it. This is not OpenAI singling out Europe; it is OpenAI responding to a regulatory environment that treats exactly this kind of feature with care.

The General Data Protection Regulation is the first source of pressure. A feature whose basic operation is recording screen activity collides directly with European data protection principles. The regulation governs what personal data is collected, the legal basis for collecting it, how it is processed, how long it is retained, and the rights of the people whose data is involved. A tool that captures on-screen content can incidentally collect personal data, both the user’s own and that of third parties who appear in the workflow, and establishing a clean legal basis and adequate safeguards for that capture is genuinely complex. A company launching such a feature in Europe without resolving these questions first would be exposing itself to serious regulatory risk, so resolving them first, before launch, is the cautious choice.

The European Union’s AI Act adds a second, newer layer. The Act imposes obligations that scale with the risk a system presents, and an autonomous agent that operates a user’s computer to complete tasks is the kind of high-capability system that attracts heightened scrutiny. Compliance with a risk-tiered framework requires assessment, documentation, and in some cases specific safeguards, none of which can be assembled overnight. For a feature combining autonomous action, screen recording, and AI processing, the AI Act and the GDPR together create a compliance burden that is rational to work through deliberately rather than to gamble on by launching into uncertainty.

OpenAI’s consistent pattern across Codex features makes the strategy legible. Computer Use on Windows excluded the same regions at launch. Memory in Codex is off by default in the EEA, the UK, and Switzerland. Personalization features were described as reaching EU and UK users later. Record & Replay’s exclusion is the latest instance of a settled approach: ship the most autonomous, most data-intensive capabilities first where the regulatory path is clearer, then extend them to Europe once compliance is established, often with additional defaults or controls. The exclusion is a sequencing decision driven by regulation, not a judgment that European users do not want the feature.

For European organizations, the regulatory reading cuts both ways and deserves to be stated plainly rather than spun. The same rules that delay access provide stronger protections around exactly the privacy and autonomy risks this feature carries, which is not nothing given that those risks are real. At the same time, the delay imposes a competitive cost: businesses in other markets begin building libraries of recorded skills and accumulating the efficiency that comes with them, while European teams wait. This trade-off, slower access in exchange for stronger safeguards, is a recurring feature of operating under European regulation, and it is neither purely a burden nor purely a benefit. Whether the eventual European version of Record & Replay arrives with full capabilities or with meaningful restrictions, and how long the wait runs, are open questions the launch does not answer, and European businesses planning around the feature should treat its arrival date and final shape as genuinely uncertain.

Recording a skill that actually works the second time

The difference between a recorded skill that holds up and one that fails on its second run usually comes down to how the recording was made. OpenAI’s guidance, combined with the realities of how Codex generalizes a demonstration, points to a set of concrete practices worth following before, during, and after a recording.

Start by choosing the right workflow. Record & Replay works best when the steps are stable and the success criteria are clear, so the first decision is whether a task actually fits. A workflow that you perform the same way every time, in applications that do not change much, with an obvious definition of done, is a strong candidate. A workflow that you improvise differently each time, or that depends heavily on judgment about what to do next, is a poor one, because there is no consistent pattern for Codex to capture. Picking a workflow you already know how to complete reliably is the foundation; you cannot demonstrate a clean version of a task you perform inconsistently.

Before recording, set the context deliberately. Tell Codex your goal and, critically, the specific inputs that will vary between uses. This is the single most important step for getting a skill that generalizes rather than one that merely repeats your exact demonstration. If you are recording a report download, say that the date range is the variable. If you are recording an issue creation, name the title, description, and label as inputs. Naming the variables up front gives Codex the frame it needs to separate the fixed workflow from the parameters, which is exactly the separation that earlier programming-by-demonstration systems struggled to infer on their own.

During the recording, keep it focused, complete, and clean. Demonstrate the whole workflow from start to finish so Codex sees the full pattern, but stop when the workflow is done rather than continuing into unrelated cleanup, because anything extra teaches Codex noise. Use realistic inputs so the demonstration reflects the real task, but keep secrets and sensitive data off the screen, which means closing unrelated windows, dismissing notifications, and making sure no passwords or confidential records are visible while you record. A focused recording of the actual task, with nothing sensitive in frame and nothing irrelevant included, is what produces a clean skill.

After recording, refine the skill rather than trusting the first draft. The drafted skill is Codex’s interpretation of what it watched, and it will have gaps a single demonstration could not fill. Read it and call out the hidden preferences that matter: naming conventions, field defaults, the decision points where the right action depends on what Codex sees. OpenAI explicitly supports asking Codex to refine the skill further, and this editing pass is where a workable recording becomes a reliable one. The demonstration captures the steps; the refinement captures the judgment and the edge cases the steps alone do not convey.

Finally, test before you trust. A skill that succeeded on the demonstrated case has not been proven on the cases that differ from it, which are the cases that matter for a reusable automation. Replay the skill with new inputs and watch what it does before letting it run unattended on anything consequential. Confirm that the verification step actually catches a failed run rather than rubber-stamping it. The whole appeal of Record & Replay is that this entire process, from choosing the workflow to a tested, refined skill, takes minutes rather than the days an RPA build would consume. That speed is real, but it is the speed of getting to a good skill through a deliberate process, not the speed of skipping the process. A recording made carelessly produces a careless skill just as quickly.

Mistakes that quietly ruin a recorded workflow

The failures that undermine a recorded skill are mostly predictable, and most of them trace back to a handful of recording mistakes. Knowing the common ones in advance is the cheapest way to avoid producing skills that look fine and then misbehave.

The most frequent mistake is skipping the context step. Recording a workflow without first telling Codex the goal and the variable inputs leaves it to infer the structure entirely from the actions it observed, which often produces a skill that bakes in the specific values used during the demonstration. The skill then repeats the exact demonstration rather than generalizing, so it works only for the original inputs and fails or does the wrong thing for new ones. The fix is the discipline already described: name the goal and the variables before recording. The difference between a generalizing skill and a one-trick recording is frequently just whether this step was done.

A close second is recording a noisy session. A demonstration that wanders into unrelated tasks, lingers on irrelevant screens, or continues into cleanup after the workflow is complete teaches Codex extraneous steps it then has to be edited out of. The recording is supposed to capture one workflow cleanly, and every irrelevant action dilutes the signal. Keeping the session tightly scoped to the task, and stopping the moment the task is done, produces a far cleaner skill than a sprawling recording that has to be trimmed after the fact.

The most dangerous mistake is capturing sensitive data. Because the recording sees whatever is on screen, a careless session can record passwords, financial details, personal identifiers, or confidential records straight into a skill, where they may then be processed and potentially shared if the skill is distributed. This is both a privacy problem and a security one, and it is entirely avoidable with preparation: close unrelated windows, dismiss notifications that might surface private content, and make sure nothing sensitive is visible before recording starts. The instruction to use realistic but non-sensitive inputs exists precisely because this mistake is easy to make and costly when made.

A subtler error is trusting the first draft without refinement. The skill Codex drafts is a starting point, not a finished product, and treating it as finished means shipping whatever gaps the single demonstration left. A skill that was never refined to capture preferences, defaults, and decision points will handle the demonstrated case and fumble the variations. The refinement pass is not optional polish; it is where the skill acquires the judgment that one demonstration could not convey, and skipping it is a reliable way to produce a skill that fails on its second or third distinct input.

The final mistake is automating the wrong task at all. Some workflows simply do not fit Record & Replay: tasks that change shape every time, tasks that hinge on judgment Codex cannot capture from watching, tasks that are conceptual rather than graphical, and tasks consequential enough that unattended execution is unwise regardless of how well the skill works. Forcing a poorly-suited workflow into a recording produces an unreliable skill no matter how careful the recording, and recognizing when not to record is as important as recording well. The feature is sharp for stable, repetitive, graphical work and dull for everything else, and most of the disappointment it generates will come from pointing it at tasks outside that range. Matching the tool to the task is the first decision, and the one that most determines whether the result is useful.

The line between a quick skill and a packaged plugin

OpenAI draws a clear distinction between a recorded skill and a packaged plugin, and understanding where that line falls prevents a common category of frustration: trying to make Record & Replay do a job it was not designed for, or failing to graduate a useful skill into something an organization can actually maintain.

A recorded skill is the fast path. Record & Replay exists to turn a demonstrated workflow into a reusable skill quickly, with minimal friction, suited to local authoring and repo-scoped or individual use. It is the right tool when you want to capture a workflow for yourself or for a narrow context, iterate on it, and start using it. The whole value proposition is speed and accessibility: a workflow captured in minutes, by demonstration, without specialist skills. For personal automation and lightweight team use, the recorded skill is the destination, not a stepping stone.

A plugin is the distribution unit. OpenAI’s guidance is explicit that if you want to distribute a stable package across a team, bundle multiple skills together, include app integrations, add MCP server configuration, or manage install metadata, you should package the workflow as a plugin rather than relying on a recorded skill. Plugins are the installable, manageable unit for reusable skills and apps in Codex, and they can carry one or more skills along with app mappings, configuration, and presentation assets in a single package. The plugin layer is where automation becomes a managed asset of an organization rather than an artifact on one person’s machine.

The practical reading is a progression. Record to create, package to distribute. A workflow starts as a recorded skill: fast to make, easy to refine, good for the person who recorded it. If that skill proves valuable and deserves to run across a team, the path forward is not to keep sharing the raw recording informally but to package it as a plugin, where it gains stability, manageability, and the install metadata that distribution requires. This mirrors the natural lifecycle of any useful automation: prototype quickly, then formalize what works. Record & Replay owns the prototype stage; plugins own the production stage.

Getting this boundary wrong produces two distinct failures. Trying to use a quick recorded skill as if it were a stable distributed package, sharing it widely without the review and packaging a plugin entails, invites the supply-chain risks discussed earlier, because an informally shared skill carries whatever it contains to everyone who runs it. Conversely, reaching for the full plugin-building process for a one-off personal automation wastes effort on formalization a single user does not need. The boundary exists so that each tool does the job it is built for: Record & Replay for fast, local capture, and plugins for stable, governed distribution. Knowing which stage you are in tells you which tool to use, and the most common disappointment with Record & Replay comes from expecting the quick-capture tool to also be the distribution-and-governance tool, which it deliberately is not.

OpenAI’s quiet ambition to absorb everyday computer work

Record & Replay is a modest-looking feature with an immodest strategic logic behind it, and reading that logic clarifies why OpenAI built it and where the company is heading. This is not a coding feature that happens to do automation. It is a deliberate move to make Codex the layer through which routine computer work gets done, and the choice of what to build reveals the ambition.

The trajectory is unmistakable when the recent product moves are read together. Codex went from a sandboxed code runner to a desktop agent with Computer Use, then gained an integrated browser, persistent memory, scheduled tasks, mobile access, and Windows support, and now adds demonstration-based workflow capture. Each step widened the agent’s reach from code into general computer operation, and each lowered the barrier to directing it. The reported expansion of the ecosystem to many third-party integrations, the introduction of role-specific plugin bundles for functions like sales and analytics, and now a feature that lets non-developers create automations by demonstration form a coherent arc: Codex is being built to capture the budgets and the work that currently go to manual processes and to legacy automation tools.

The competitive framing makes the stakes plain. By writing recorded skills into the open agent skills standard, OpenAI competes on execution rather than lock-in, the same logic Anthropic used when it opened the standard in the first place. The contest among OpenAI, Anthropic, Google, and Microsoft is increasingly not about whether an agent can operate a computer, a capability that has become common, but about who offers the best way to teach it, reuse what it learns, keep it safe, and fit it into how organizations work. Record & Replay is OpenAI’s bid on the teaching-and-reuse front: the lowest-friction way yet to turn a human workflow into agent-executable form. Whether that bid holds depends on whether competitors match the demonstration approach, which nothing structural prevents them from doing, since they all write into the same format.

The deeper ambition is to position Codex as the interface between people and the long tail of computer work that never got automated. Traditional automation captured the high-volume, high-value processes that justified an RPA project and left everything else manual, because the cost of automating a smaller task exceeded its value. Record & Replay attacks that long tail directly by collapsing the cost of automation to a single demonstration. If the cost of automating a workflow drops low enough, the universe of automatable work expands enormously, and OpenAI is betting that an agent which any worker can teach by demonstration becomes the natural home for all the routine tasks that were previously beneath the automation threshold. That is a far larger market than the one RPA ever addressed, because most routine computer work lives in that long tail.

The honest assessment is that the ambition is real and the current product is an early, constrained expression of it. Record & Replay launched macOS only, behind a Computer Use requirement, excluded from major markets, with meaningful limits on reliability, security, and the tasks it suits. It is not yet the universal automation layer the strategic logic points toward. But the direction is clear and consistent, and the gap between the constrained feature of today and the ambition behind it is exactly the gap OpenAI’s recent pace suggests it intends to close. The feature matters less for what it does today than for what it signals: a deliberate campaign to make demonstrating a task to an AI the default way routine computer work gets automated, with OpenAI’s agent at the center of it. The mechanics are simple. The intent is not.

Questions the launch leaves open

A feature this new, sitting on capabilities this fast-moving, leaves a set of questions the available evidence cannot yet settle. Naming them honestly is more useful than pretending the picture is complete, and each one bears on whether Record & Replay becomes a quiet utility or a genuine shift in how routine work gets done.

The first is how well the generalization actually holds up in messy, real-world workflows. The decades-old promise of programming by demonstration failed repeatedly on exactly this point, and while large language models with vision are a far stronger inference engine than anything earlier systems had, the public record so far is mostly OpenAI’s own framing and early reactions rather than independent evidence across a wide range of difficult tasks. Whether recorded skills generalize reliably outside clean demonstrations, or whether they prove fragile in the same places their predecessors did, is the central empirical question, and it will be answered by usage over the coming months rather than by anything in the launch materials.

The second is whether and when Windows and Europe get the feature, and in what form. The macOS-only launch and the exclusion of the European Economic Area, the UK, and Switzerland are the constraints that most limit the feature’s reach today, and OpenAI has not committed to a timeline for either. The Windows question is partly technical, given the foreground-only model of Computer Use there, and partly a matter of priority. The European question is regulatory, and the pattern of OpenAI’s other features suggests Europe eventually gets these capabilities, often with additional defaults or restrictions. How long the wait runs and whether the eventual versions match the macOS capability are unresolved.

The third is how the security and privacy risks play out at scale. The exposure to prompt injection, the capture of sensitive and third-party data during recording, and the propagation of unsafe steps through shared skills are real today, and the mitigations available reduce rather than eliminate them. What is not yet known is how these risks manifest once recorded skills are running widely in production, whether the documented failure patterns of agentic systems show up frequently in practice, and whether OpenAI strengthens the native controls beyond the coarse on-off switch. The security literature is clear that the underlying problems are unsolved; how badly they bite in this specific feature is an open question.

The fourth is how the labor effects accumulate. The near-term impact is task automation rather than wholesale displacement, bounded by the feature’s current limits, but the trajectory points toward broader automation of routine computer work as those limits lift. Whether the optimistic framing, that automating the boring parts shifts work toward human judgment, holds for roles that are mostly routine execution is genuinely uncertain, and confident predictions in either direction outrun the evidence. The honest position is that this is a real force on routine work whose ultimate effect on employment is not yet knowable.

The fifth is whether OpenAI’s competitors match the demonstration approach, and how fast. Record & Replay’s distinctive contribution is demonstration-based authoring, but nothing structural prevents Anthropic, Google, or Microsoft from adding the same, especially since they all write into the shared skills standard. If the demonstration approach proves valuable, the likely outcome is convergence rather than a durable advantage for OpenAI, which would be good for users and would turn the contest back toward execution quality, safety, and platform fit. Whether OpenAI’s head start becomes a lasting edge or a brief lead that rivals erase is among the more interesting things to watch.

None of these questions undercuts what Record & Replay already is: a credible, low-friction way to turn a demonstrated workflow into a reusable skill, built on an open standard, arriving as the logical next step in Codex’s transformation into a general automation agent. They simply mark the boundary of what can be said with confidence today. The feature is real and its direction is clear; its reliability at scale, its reach across platforms and regions, its risk profile in practice, its effect on work, and its competitive durability are the things the next year will decide, and anyone planning around it should hold those judgments loosely until the evidence arrives.

Practical answers about recording and replaying Codex skills

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Record & Replay – Codex OpenAI’s official documentation for the feature, covering how recording works, the generated skill, replay, tips for better recordings, and the Computer Use requirement.

Changelog – Codex OpenAI’s Codex changelog, which records the addition of Record & Replay and the exclusion of the European Economic Area, the United Kingdom, and Switzerland at launch.

Agent Skills – Codex OpenAI’s documentation on skills, the SKILL.md authoring format, progressive disclosure, and the distinction between skills and plugins.

Computer Use – Codex app OpenAI’s documentation on Computer Use, including the macOS Screen Recording and Accessibility permissions and the data-controls note covering screenshots.

Build plugins – Codex OpenAI’s guidance on packaging skills as plugins for stable distribution, bundling, app integrations, and install metadata.

Introducing the Codex app OpenAI’s announcement of the Codex desktop app for macOS and its later expansion to Windows.

Codex rate card OpenAI’s help-center documentation of the April 2026 move to token-aligned Codex pricing across Plus, Pro, Business, and Enterprise plans.

Anthropic Opens Agent Skills Standard Unite.AI’s coverage of Anthropic releasing the agent skills standard in December 2025 and its rapid adoption by OpenAI, Microsoft, Google, GitHub, and others.

SKILL.md: The Open Standard for AI Agent Skills A technical reference on the agent skills standard, the SKILL.md structure, progressive disclosure tiers, and tool-specific extensions including Codex’s openai.yaml metadata.

OpenAI Codex Becomes Desktop Agent Tech Times on the transformation of Codex from a sandboxed cloud code-runner into a desktop agent with background Computer Use, memory, scheduled tasks, and mobile access.

OpenAI Codex Computer Use Now on Windows, Europe Excluded Tech Times on the May 2026 Windows release of Computer Use, the foreground-only model on Windows, and the exclusion of European regions.

OpenAI Codex desktop update for macOS Help Net Security on the April 2026 Codex update bringing computer use, personalization, and memory to macOS, with expansion to EU and UK users planned later.

Anthropic says Claude can now use your computer CNBC on Anthropic’s computer-use capability for Claude in Cowork and Claude Code, including the Dispatch feature for assigning tasks from a phone.

OpenAI introduces Record & Replay plugin for Codex Crypto Briefing’s coverage of the Record & Replay launch, describing the demonstrate-and-capture flow and the macOS-only limitation.

Prompt injection still drives most agentic AI security failures Help Net Security on the OWASP findings that coding agents, including Codex, drive most new agentic attack data, and on documented unprovoked agent failures.

Prompt Injection: The #1 AI Security Threat in 2026 An overview of prompt injection as the leading AI security threat, why language models cannot reliably separate trusted instructions from untrusted input, and partial mitigations.

When prompts become shells: RCE vulnerabilities in AI agent frameworks Microsoft Security on a vulnerability path where a single prompt escalated into host-level remote code execution in an AI agent framework.

VPI-Bench: Visual Prompt Injection Attacks for Computer-Use Agents Research demonstrating how instructions embedded in what a computer-use agent sees on screen can hijack its behavior and expose sensitive data.

What is Robotic Process Automation UiPath’s description of RPA, its evolution, and its repositioning as the execution layer for agentic automation.

Best Robotic Process Automation Reviews Gartner’s definition of RPA as software that automates tasks by emulating human interaction with an application’s user interface through recorded or programmed scripts.

Why UiPath is re-designing its platform around agents Diginomica on UiPath’s argument that AI is suited to deciding actions while structured automation provides the deterministic, governed, auditable execution complex processes need.

AI RPA: What It Is and How Agentic AI Replaces Traditional RPA An analysis of the brittleness of selector-based RPA, the maintenance burden it imposes, and the shift toward AI-native automation that removes fragile selectors.

RPA Stalwart UiPath Moves Into Agentic AI Realm AI Business on the established RPA vendors embracing agentic AI and the historical roots of process automation in 1990s workflow automation.

Codex (AI agent) A reference overview of Codex’s history, from the April 2025 CLI release through the desktop app, model upgrades, and growth in weekly active users.