Locked out of wp-admin? Why WP-CLI works when wp-login.php doesn’t

A forgotten password, a security plugin that blocked your own IP by mistake, a plugin bug that turns the admin screen white — the causes vary, but the result is the same: you can’t log in to wp-admin.

Note: WP-CLI is a command-line tool for managing WordPress, invoked as wp. It operates directly on the server, without going through a browser.

This is exactly the situation where WP-CLI is useful. It works here because it never touches wp-login.php — it reads and writes the WordPress database and filesystem directly, so a broken login screen doesn’t affect it at all.

Why WP-CLI keeps working when wp-admin doesn’t

A normal login follows the path: browser → wp-login.php → authentication → wp-admin. If anything along that path is broken — a plugin throwing a fatal error during authentication, a security plugin blocking your IP, a fatal error in the admin theme — the login itself can’t complete.

WP-CLI connects over SSH and reads/writes the wp_users and wp_options tables (and the filesystem) directly. The code in wp-login.php is never executed, so problems on that path don’t matter. This does require that SSH access itself still works — on most hosting providers, SSH is a separate access path from the admin dashboard, so it usually still works even when wp-admin doesn’t.

Scenario 1: Forgotten password

# List administrator accounts
wp user list --role=administrator --fields=ID,user_login,user_email

# Overwrite the password directly
wp user update 1 --user_pass='a-strong-new-password'

wp user update writes the new password directly to the database row — no password-reset email, no token, no waiting on a delivery that might land in spam or not arrive at all.

Scenario 2: A security plugin blocked your own IP

Login-attempt-limiting plugins occasionally misclassify legitimate activity as an attack and add the working IP to a block list.

# Deactivate the plugin responsible for the block
wp plugin deactivate <plugin-causing-the-lockout>

# Re-enable it later, after reviewing its configuration
wp plugin activate <plugin-name>

Deactivating the plugin also disables whatever block list or rate-limiting logic it was enforcing. If the cause isn’t clear, deactivate everything to isolate the problem:

# Stop all plugins to isolate the cause
wp plugin deactivate --all

# After confirming you can log in, re-enable them one at a time
wp plugin activate <plugin-a>
wp plugin activate <plugin-b>

Re-enabling one plugin at a time and checking login access after each step identifies exactly which plugin caused the lockout.

Scenario 3: No administrator account exists

A mistake during an offboarding cleanup can leave a site with no administrator account at all.

# Create a new administrator account
wp user create rescue_admin admin@example.com --role=administrator --user_pass='a-strong-password'

wp user create creates an administrator account immediately, with no email verification or plugin approval flow in the way. After recovery, either delete this emergency account or scope it down to the minimum permissions actually needed.

Scenario 4: A blank white screen in wp-admin

A PHP fatal error in a plugin frequently shows up as a blank white screen in wp-admin. Deactivating the offending plugin usually resolves it.

# After identifying the plugin from the error log
wp plugin deactivate <plugin-name>

If WP-CLI itself crashes while loading plugins, starting WP-CLI with --skip-plugins --skip-themes is the step that has to come first — none of the commands above will run until WP-CLI itself starts successfully.

What to verify after recovery

# Confirm no leftover emergency accounts remain
wp user list --role=administrator --fields=ID,user_login,user_email

# Confirm no plugins were left deactivated by mistake
wp plugin list --status=inactive

Any account or password created for emergency recovery should be removed or changed once the site is stable. Leaving it in place turns the fix itself into the next security gap.

Summary

What every scenario above has in common is that WP-CLI never touches wp-login.php — it reads and writes the WordPress database directly. Like serialized-safe string replacement, where the s:N: byte-length prefix matters, this is WP-CLI operating one layer below the admin dashboard — and that’s exactly the layer that matters during a lockout.