Codex Record and Replay for QA can turn a browser workflow that is easier to demonstrate than describe into a reusable skill. A QA engineer performs a short regression once, Codex observes the sequence, and the generated skill captures the inputs, actions, decision points, and result checks for later use.
This is useful for repetitive staging checks such as creating a test customer, submitting a support request, or confirming that a report can be downloaded. It is not a replacement for deterministic automation. Treat every replay as an assisted test execution whose result still needs independent evidence and human judgment.
What Record & Replay does
OpenAI’s official documentation says Record & Replay is available on macOS and requires Computer Use to be available and enabled. Initial availability excludes the European Economic Area, the United Kingdom, and Switzerland. The Codex app changelog describes it as a feature that turns a demonstrated workflow into a reusable skill.
During recording, Codex observes the actions and window content needed to learn the workflow. Recording continues until you stop it. Afterward, Codex drafts a skill that describes when to use the workflow, the inputs it needs, the steps to follow, and how to verify the result. A replay may use Computer Use, browser actions, installed plugins, or a combination.
Choose a safe, stable QA workflow
OpenAI recommends starting with steps that are stable and success criteria that are clear. For this tutorial, use a staging-only checkout smoke test with synthetic data:
- Open the approved staging storefront.
- Add one known test product to the cart.
- Apply a non-sensitive test coupon.
- Complete checkout with a sandbox payment method.
- Verify the confirmation page shows the expected order state.
- Capture the order reference and visible result for later comparison.
Avoid production accounts, real payment details, customer data, secrets, password managers, private messages, or unrelated windows. OpenAI explicitly advises using realistic inputs without secrets or sensitive data. Create a disposable test account and resettable fixture before recording.
Record the regression flow
1. Define inputs and stop conditions
Write down the values that may change between runs: environment URL, product, coupon, account, and expected confirmation state. Also define stop conditions. The run should stop if navigation leaves the approved staging origin, a production banner appears, authentication changes unexpectedly, or a destructive action is requested.
Record this staging checkout smoke test as a reusable QA skill. The variable inputs are staging URL, test account, product name, coupon, and expected order state. Never enter production, do not use real customer or payment data, stop on unexpected authentication, and preserve the visible confirmation result for review.
2. Start recording deliberately
In the ChatGPT desktop app, select ChatGPT in Work mode or select Codex, then open Plugins. Use the plus menu, choose Record a skill, review the suggested prompt, and approve recording only when the test environment is ready.
Keep the demonstration short and complete. Explain hidden intent when it matters: why a certain product is used, which banner proves staging, and what order state counts as success. Do not continue into unrelated cleanup after the last assertion. Stop recording from the menu bar, overlay, or by telling Codex that the workflow is complete.
3. Inspect the generated skill
Do not replay immediately. Review the draft for four things:
- Scope: it names the staging origin and refuses production.
- Inputs: variable values are parameters rather than hard-coded secrets.
- Decision points: unexpected banners, missing inventory, or authentication changes cause a stop.
- Verification: success requires an observable order state, not merely a click sequence.
Refine hidden preferences such as naming conventions, default test data, evidence location, and whether cleanup is safe. OpenAI recommends explicitly adding preferences and decision points that were not obvious from the demonstration.
Replay with changed test inputs
Start a new chat and ask Codex to use the generated skill. Supply only the approved values that differ for this run:
Use the recorded staging checkout skill with product QA-SAMPLE-02, coupon REGRESSION10, and expected state Confirmed. Stop before any production origin or real payment request. Return the observed result, order reference, and any deviation from the recorded path.
Watch the early navigation and permission prompts. A reusable skill provides context; it does not guarantee that the application, test data, or environment still matches the recording. If the UI has materially changed, stop and revise the skill instead of forcing it through a different flow.
Validate the replay independently
A completed replay is not proof that the feature is release-ready. Verify the order through an independent source such as a test API, database fixture, approved admin screen, or deterministic automated check. Confirm that the displayed order reference exists, the coupon calculation is correct, and no duplicate order was created.
Preserve an evidence bundle containing the environment and build, timestamp, sanitized inputs, observed confirmation state, replay deviations, and independent verification result. If the skill reports a defect, reproduce it manually or with an existing automated test before filing the issue.
Practical acceptance checklist
- The workflow runs only in an approved staging environment.
- All test data is synthetic, resettable, and non-sensitive.
- Variable inputs are clearly named in the generated skill.
- Unexpected origins, login states, or destructive actions trigger a stop.
- Success is tied to a business outcome, not just completed clicks.
- The replay result is verified through an independent system or automated check.
- A human reviews deviations and decides whether the skill needs revision.
Common failure modes
Recording too much: a long demonstration captures irrelevant actions and fragile detail. Record one bounded outcome.
Leaking sensitive data: recording observes relevant window content until stopped. Close unrelated applications and use sanitized fixtures.
Hard-coding volatile values: product IDs, dates, and account names should be explicit inputs when they vary.
Assuming visual success is system success: a confirmation page can render while downstream processing fails. Verify through an independent source.
Ignoring platform limits: the documented feature is macOS-only at publication time, requires Computer Use, and is initially unavailable in specific regions.
Screenshot plan
- The staging test charter with approved inputs and stop conditions.
- The Plugins menu showing Record a skill.
- The permission prompt immediately before recording begins.
- The short staging checkout demonstration.
- The generated skill with inputs, steps, and verification criteria.
- A replay request using a different synthetic product and coupon.
- The independent order-state check and final evidence bundle.
FAQ
Is Codex Record & Replay available on Windows?
No. OpenAI currently documents Record & Replay as available on macOS.
Does it require Computer Use?
Yes. Computer Use must be available and enabled. Managed organizations can also disable it through their requirements configuration.
Can I record a production workflow?
For QA adoption, prefer a controlled staging environment with synthetic data. Recording production can expose sensitive information or perform consequential actions.
Does a successful replay replace automated regression?
No. Replays can help execute repetitive flows, but deterministic tests, security and accessibility checks, monitoring, and human release approval remain necessary.
When should the skill be rebuilt?
Review it when the UI, authentication, test data, business rules, or success criteria change materially, or when replays repeatedly deviate from the recorded flow.
Conclusion
Codex Record and Replay for QA is most valuable when the workflow is short, stable, easy to observe, and awkward to explain repeatedly. Keep it inside staging, remove secrets, parameterize changing inputs, define explicit stop conditions, and independently verify every material outcome. That turns a demonstration into a useful QA accelerator without weakening the release gate.
References