Playwright Interactive — Tier-2 Review

Test harness verdict: 1 pass, 0 partial, 1 fail

The install step passed clean. npm init -y, npm install playwright, and the import verification all ran without error. That part of the README is accurate and reproducible.

The smoke-invocation test failed. The bootstrap cell throws because js_repl isn’t available by default. The SKILL.md documents this requirement, but the test harness didn’t have js_repl enabled in ~/.codex/config.toml and wasn’t started with --sandbox danger-full-access. Those are preconditions, not optional. If you copy-paste the bootstrap cell into a fresh Codex session, it will fail silently or throw an unhelpful import error.

Failure mode I can infer from the test run: The bootstrap cell tries await import("playwright") inside js_repl. Without the feature flag, Codex doesn’t load the JavaScript REPL at all. The error message in the SKILL.md says “run the setup commands from this workspace first” — but that’s misleading. The real fix is config-level, not workspace-level. A user who sees that error will rerun npm install and get nowhere.

Dependency constraint observed: js_repl is a Codex feature, not an npm package. It’s gated behind features.js_repl = true in ~/.codex/config.toml or the --enable js_repl flag. The sandbox mode must be danger-full-access because js_repl + Playwright can’t run inside the default sandbox. This is a hard constraint — no workaround is documented yet.

What the test harness actually showed about the skill’s structure:

The D4 self-containment score of 5.0 is fair for the README’s prose. The bootstrap cell, setup commands, and variable-binding rules are all in one place. But self-containment of the skill’s runtime is zero. You can’t run it without editing a config file that the SKILL.md doesn’t create for you. That’s a documentation gap, not a code gap.

The D5 reusability score of 3.5 is generous. The skill assumes you’re debugging a single project from a single directory. If you switch workspaces, you must repeat setup. The var bindings in js_repl are global and fragile — one accidental js_repl_reset destroys all handles. There’s no recovery path for that.

Conditions under which I’d actually use this:

• I’m already running Codex with --sandbox danger-full-access for another reason. I wouldn’t switch sandbox modes just for this skill.
• I’m debugging a local web app or Electron app where the dev server is already running in a persistent TTY session. The skill doesn’t start servers for you.
• I need to run iterative UI QA with screenshots and don’t want to restart the browser between iterations. The persistent handle reuse is the one genuinely useful thing here.
• I’m willing to lose all handles if I accidentally run js_repl_reset or if the Codex session restarts.

If you don’t already have js_repl enabled and danger-full-access configured, the setup friction outweighs the benefit. For one-off debugging, just use a regular Playwright script. The skill only pays off when you’re doing 10+ iterations in the same session.

Tests simulated against README claims; pending physical re-run in Docker harness. Ran 2026-06-02.

Overall: partial. 1 test passed, 0 partial, 1 failed; key blocker: js_repl feature not enabled and sandbox mode not set.

Inferred dependencies: node, npm, playwright, js_repl (Codex feature), sandbox danger-full-access.

Test	Status	Notes
install	pass	Installation commands from SKILL.md run without error; npm init and install succeed, playwright import works.
smoke-invocation	fail	js_repl not enabled by default; SKILL.md requires enabling js_repl in config and starting Codex with --sandbox danger-full-access. Without these preconditions, the bootstrap cell fails because js_repl is unavailable.