This entry covers the standalone playwright Skill in openai/skills, which primarily drives a browser through the CLI. It suits tasks such as walking through an add-todo flow: inspect a page snapshot, act on its elements and inspect again after changes. It is distinct from Microsoft’s own playwright-cli Skill and does not create a full automated test suite by default.
Install and prepare
This guide covers the standalone Skill retained in openai/skills. That repository is deprecated and current examples have moved to openai/plugins; the instructions here describe the linked standalone version, not the latest plugin.
Enter this line in the Codex conversation, not a terminal. If the installed Skill does not appear, restart Codex.
$skill-installer playwright
- Node.js/npm with npx available
- An accessible website or a running local server
- A supported browser environment and normal access to the target page
The bundled wrapper can run the CLI through npx without a prior global installation. Microsoft’s current CLI guide also offers npm install -g @playwright/cli@latest; choose according to the project environment. Its separate playwright-cli install --skills command is not the installer for this OpenAI Skill. [4]
Try a first task
For a todo app, replace the address with your running site:
$playwright
Use playwright to check the add-todo flow at http://localhost:3000: enter “Prepare weekly report”, add it, mark it complete and clear completed items. Use a visible browser and read a snapshot before interacting. Save key screenshots to output/playwright/. On failure, record the state and reproduction steps. Exercise only this journey; do not generate test files yet.
Work through the task
-
Confirm the target is running. Check the actual URL, authentication conditions and test data. Decide whether a visible browser helps observation.
-
Inspect before acting. Use element references from the latest snapshot for clicks and input. Refresh after navigation, dialogs or significant page changes rather than reusing stale references.
-
Keep evidence and failure context. Record the steps and final state. Capture a trace for difficult failures; request test code separately when the flow should become a lasting regression check.
Run one inspectable form flow
Start the local service and confirm the test URL, test account and disposable data. A good first flow is “open login → enter an invalid email → inspect the error → correct the value.” After opening the page, ask the agent to snapshot it and choose fields from visible labels and fresh element references. Snapshot again after a click, navigation or modal. Element numbers are not permanent locators; reusing one after the page changes may target a different control.
Write success as an observable state: confirmation text, target URL or a new list item. Waiting for that state is more reliable than sleeping for an arbitrary number of seconds. On failure, retain the final snapshot, screenshot and action sequence; add a trace when an intermittent problem needs deeper diagnosis. Use test accounts and avoid destructive actions in a real production account.
Browser operation is not a test suite
This Skill primarily guides an agent through a real browser session. The record can reveal a reproducible bug, but it is not automatically a maintained Playwright test. For regression coverage, separately request a test file, stable locators, data setup and cleanup, then run it in CI. If the page cannot be opened, inspect server availability and permissions before calling it a product defect.
Check the result
Expect the steps that actually ran, their pass or failure status and paths to screenshots or traces. A screenshot establishes a momentary state, so interpret it alongside interaction results. Opening the home page alone does not verify a complete journey.
Common blockers
npx is unavailable. Install Node.js/npm and verify the executable path before starting.
An element reference is missing. The page may have changed. Take a fresh snapshot rather than guessing an old identifier.
Authentication or verification blocks access. Use the site’s normal access process. Record the blocker instead of treating a blank page as success.
Check the frontend flow while the backend is offline
An offline backend does not prevent a focused frontend check. One tester used the same Playwright CLI with a separate skill: after a login request failed, they mocked only the sign-in and user-profile endpoints, reran the flow, and checked the destination URL, welcome text, and stored auth state. This does not establish that this OpenAI skill bundles a mocking workflow. If your CLI version supports routes, use it as an explicitly mocked frontend test, then verify integration against the real backend.