Reset a WordPress password with WP-CLI.

When WP-CLI is the right recovery path

Use WP-CLI when you administer the server or have approved shell access to the WordPress installation. It is usually safer than editing user_pass in phpMyAdmin because the normal WordPress user-update path handles password hashing. It is not a shortcut for accessing a site you do not administer.

Reset one account without exposing the password

First move to the directory containing the site’s wp-config.php. Confirm the account before you touch it; WP-CLI accepts a login, email, or numeric user ID. Listing a small set of fields is a useful preflight check.

On a site with hundreds of subscribers, filtering by role is the difference between a four-row answer and four pages of scrolling. Drop --role and add roles to the field list when you need to see what a specific account actually is.

Then use the prompt flag. It asks for the new password interactively, keeping the value out of shell history and the command itself.

Replace USERNAME with the login, email, or ID you confirmed. Enter a unique, strong password when prompted and store it in a password manager. Do not paste it into a shared terminal, support ticket, or recorded session.

$ wp user list --role=administrator --fields=ID,user_login,user_email
+----+------------+---------------------+
| ID | user_login | user_email          |
+----+------------+---------------------+
| 1  | admin      | owner@example.com   |
| 7  | editor-kim | kim@example.com     |
+----+------------+---------------------+

$ wp user update 1 --prompt=user_pass
1/1 [user_pass]:
Success: Updated user 1.

$ echo $?
0

Two things confirm the reset rather than assuming it: the literal Success: Updated user 1. line, and an exit status of 0. WP-CLI exits non-zero and prints an Error: line when it fails, which matters if you are running this from a script or a deploy hook where nobody is reading the output. A numeric ID is the safest target — a login can be ambiguous across a network, an ID never is.

If email works on the site and you would rather not choose the password yourself, wp user reset-password <user> generates a strong one, saves it, and emails the account. It is the closest command-line equivalent of the normal “lost your password” flow, and it fails quietly if mail delivery is broken — which is its own diagnosis.

Choose the target before running the command

On a server with several WordPress installs, add --path=/path/to/site to make the target explicit. On multisite, use --url=https://example.com when the account belongs to a particular site. The goal is simple: identify the site and account first, then make one deliberate change.

# Several WordPress installs on one server: name the directory.
wp user update 1 --prompt=user_pass --path=/var/www/example.com

# Multisite: name the site the account should be resolved against.
wp user update 1 --prompt=user_pass --url=https://shop.example.com

# Running as root stops WP-CLI outright. Run as the site's own user
# rather than reaching for --allow-root.
sudo -u www-data wp user update 1 --prompt=user_pass

The last line is the one that catches people mid-incident. WP-CLI stops with Error: YIKES! It looks like you're running this as root. rather than running as the wrong user and leaving files your web server cannot read. Switching to the site's own user with sudo -u is the fix; --allow-root exists, but it suppresses the warning instead of addressing it.

On a network, remember what --url does and does not change: WordPress accounts are shared across the whole network, so the password you set is the password everywhere. The flag only decides which site's context the command resolves against — see where the users table lives on multisite if that distinction is new.

If the command does not work

An error before WordPress loads often means you are in the wrong directory, the path is incorrect, or the command cannot read the configuration. A successful update followed by a failed sign-in can point to a security plugin, an external identity provider, a different site in a network, or a browser session issue.

Do not keep repeating changes. Review the exact command output, confirm the user with wp user list, and then use the password reset troubleshooting guide to narrow down the next check.

If you want to confirm the hash WP-CLI wrote before testing a live login, copy the value from user_pass and check it against your new password with the local hash verifier — nothing leaves your browser.

Installing WP-CLI when the host has not

WP-CLI is a single PHP archive. It needs no root, no package manager, and no permission beyond writing to your own home directory — which makes it available on far more shared hosting than people assume. Verify the download before you run it: a tool that edits your database is exactly the thing worth checking a hash on.

# Download the tool and the checksum published beside it.
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar.sha512

# The published file holds the bare hash, so pair it with the filename
# before checking. Do not continue unless this prints "OK".
echo "$(cat wp-cli.phar.sha512)  wp-cli.phar" | shasum -a 512 --check

# Then make it runnable. ~/bin keeps it in your account, no root needed.
php wp-cli.phar --info
chmod +x wp-cli.phar && mv wp-cli.phar ~/bin/wp

If ~/bin is not on your PATH, call it as ~/bin/wp or leave the phar in the site directory and run php wp-cli.phar instead — neither is worse for a one-off recovery. The official installing guide covers the package-manager routes and the Windows equivalents.