A command rejected by the WordPress Playground Terminal may be valid on your server but unsuitable for the browser runner. First identify whether you are in PHP or WP-CLI mode, then reduce the command to a short read-only check against the active Playground.
Know what the runner does
The Playground Terminal documentation describes separate PHP and WP-CLI modes. PHP runs with WordPress loaded; variables do not persist between separate submissions. Database changes do persist in the active site. The runner has no interactive TTY and rejects interactive or long-running commands. It is not a full SSH shell.
That distinction matters when copying a setup recipe. A recipe may mix shell environment assignments, package installation, interactive questions and WordPress commands. Pasting the whole recipe into one runner input does not establish that the plugin itself is incompatible.
Start with identity, not a write
Open Dev Tools, then Terminal. In WP-CLI mode, run wp core version as a standalone command. Next inspect wp option get siteurl and confirm that you recognize the active test site. Do not paste production credentials into the runner.
If the simple command fails, retain its exact error and the Playground configuration. If it succeeds, inspect whether the plugin that supplies your failing command is active. A WooCommerce command requires the relevant plugin; a command from a custom extension requires that extension too.
Mode: PHP or WP-CLI matches input. Extension: Command provider is active. Scope: Synthetic current Playground. Retry: Check before creating duplicates. Explanatory checklist, not a customer test result.
Classify the failure
| Symptom |
Useful next step |
| PHP parse error after pasting a CLI command |
Select WP-CLI mode |
| Unknown command namespace |
Check the providing plugin and its version |
| Request for interactive input |
Use a supported non-interactive alternative or local environment |
| Long task rejected |
Reproduce with a bounded fixture outside the browser runner |
| Variable missing on a later PHP run |
Include needed setup in the same submission |
Do not add --yes indiscriminately. On a destructive command it can remove a meaningful safeguard. Read the command's own reference and know what data it changes before selecting a non-interactive path.
Keep reproduction data under control
Use synthetic posts and test accounts. Before retrying a create operation after an ambiguous result, list existing records and check whether the first attempt completed. Re-running a create command can produce duplicates, making the next investigation harder.
Keep a tiny transcript: input mode, command, exact output, site version, active extension version and expected record. If a task needs a daemon, host filesystem access or a long import, reproduce that portion in a proper development environment. A successful Playground example is not evidence that production networking, cron or mail delivery works.
For email-specific limitations, see why Playground's Email tool may show no messages. Capturing a notification and delivering it to a real inbox are separate checks.
When the reproduction is ready
A useful report includes the smallest command that fails and a supported command that succeeds in the same session. Export only a sanitized test fixture if someone else must reproduce it. HandL WP can help isolate a WordPress failure when the difference between browser runner and server environment remains unclear.
Source: Playground Terminal and Dev Tools Dock. No production command execution is implied by this guide.
References reviewed October 17, 2026. Examples are explanatory, not customer test results.