You opened LocalWP’s Site Shell, ran a WP-CLI command, and got hit with either a MySQL connection error or a wall of PHP extension warnings. You’re not alone — this is one of the most common LocalWP pain points on Windows, and it happens because LocalWP’s bundled PHP and MySQL don’t behave like a standard server environment.
The error messages that give it away:
Error: Failed to get current SQL modes. Reason: ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost:3306' (10061)
Error: Failed to get current SQL modes. Reason: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Error: Your PHP installation appears to be missing the MySQL extension which is required by WordPress.
Warning: Failed loading Zend extension 'php_opcache.dll'
Warning: Can't load module 'php_xdebug.dll' as it's linked with 14.42, but the core is linked with 14.29
Why this happens
LocalWP runs its own bundled MySQL on a non-standard port (typically 10016 or similar) and connects to it via a Windows named pipe socket — not TCP port 3306. When you run WP-CLI from outside LocalWP’s controlled environment, it tries to connect via TCP on port 3306, which isn’t listening. Access denied.
The PHP extension warnings happen when Git Bash or PowerShell pick up a different system PHP instead of LocalWP’s bundled PHP. That system PHP loads a different php.ini that points to extension DLLs compiled against a different Visual C++ runtime — they fail to load, and mysqli goes missing with them.
The solution is to stop fighting LocalWP’s environment and work within it.
Step 1: Confirm your LocalWP Site Shell is set to CMD
Open LocalWP → Preferences and find the Shell setting. Set it to CMD — not Git Bash, not PowerShell.
Git Bash loads the wrong PHP binary. PowerShell has quote-escaping issues with WP-CLI. CMD is the only shell where LocalWP correctly pre-loads its own PHP and MySQL socket environment before you land at the prompt.
You’ll see this banner when Site Shell opens correctly:
Setting Local environment variables...
----
WP-CLI: WP-CLI 2.12.0
PHP version 8.4.10 (C:\Users\...\php-8.4.10+0\bin\win64\php.exe)
MySQL: mysql Ver 8.0.35
----
Loaded Shell for Local Site: Pasarol
If you see this banner, you’re in the right environment.
Step 2: Fix wp-config.php DB_HOST
Open wp-config.php in your site root and find the DB_HOST line:
define( 'DB_HOST', 'localhost' );
Keep it exactly as localhost with no port number. Do not change it to localhost:10016 or any other port.
LocalWP’s PHP connects to MySQL via a Windows named pipe socket. The localhost hostname triggers socket mode. If you add a port number, PHP switches to TCP mode and the connection fails — even though port 10016 works fine in external tools like AdminNeo.
Step 3: Use AdminNeo for all database queries
wp db query will never work reliably in this environment. Use LocalWP’s built-in database tool instead:
- Open LocalWP
- Click your site name
- Click the Database tab
- Click Open AdminNeo
Run any SQL directly there:
SHOW TABLES LIKE 'wp_pasarol_%';
DESCRIBE wp_pasarol_orders;
SHOW INDEX FROM wp_posts WHERE Key_name LIKE '%fulltext%';
AdminNeo connects through LocalWP’s own socket layer, so it always works regardless of port configuration.
Step 4: Use CMD-safe syntax for all WP-CLI commands
CMD doesn’t handle single-quote-wrapped strings the same way bash does. Use double quotes on the outside and single quotes on the inside:
wp eval "echo has_action('pasarol_listing_published') ? 'OK' : 'missing';"
Not this:
wp eval 'echo has_action("pasarol_listing_published") ? "OK" : "missing";'
The second form causes a “Too many positional arguments” error in CMD because CMD splits on spaces inside single-quoted strings.
For filtering output, use findstr instead of grep:
wp cron event list | findstr "pasarol"
For reading log files, use type instead of cat:
type wp-content\debug.log
Use backslashes for file paths in CMD:
vendor\bin\phpcs -i
Step 5: Reactivate the plugin after any activation-hook changes
WordPress only runs activation hooks when a plugin is freshly activated — not when it’s already active. If you add database tables, register custom roles, or schedule cron events, those changes won’t take effect until you deactivate and reactivate:
wp plugin deactivate your-plugin
wp plugin activate your-plugin
Then verify in AdminNeo that your tables exist, or run:
wp role list
wp cron event list
Skipping this step is why tables appear missing and roles don’t show up after new code is deployed.
FAQ
Why does wp db query work in regular CMD but not for database schema commands? It doesn’t — the MySQL connection error affects all wp db subcommands. WP-CLI’s db commands use mysqlcheck, mysqldump, and mysql binaries that attempt TCP connections. LocalWP’s socket setup doesn’t expose those binaries in a way that works from CMD. Use AdminNeo for everything database-related.
Can I use Git Bash instead of CMD for WP-CLI? No. Git Bash uses whichever php binary appears first in your Windows PATH — usually a system PHP installation compiled against a different Visual C++ runtime than LocalWP’s PHP. Every extension (mysqli, curl, openssl, mbstring) fails to load, and WP-CLI can’t connect to the database at all.
My DB_HOST was already set to localhost and I still get connection errors from regular CMD. Regular CMD opened outside LocalWP Site Shell doesn’t have LocalWP’s environment variables pre-loaded. The socket path isn’t configured. Only commands run from within LocalWP’s Site Shell (CMD) have the correct environment. Always open Site Shell through the LocalWP UI, not by opening CMD separately.
Why does the Site Shell banner say “Setting Local environment variables” — what does that actually do? LocalWP injects environment variables that point WP-CLI and PHP to its bundled binaries and configure the MySQL socket path. Without those variables, any PHP or WP-CLI command falls back to whatever is installed system-wide — which is usually wrong or incomplete.
Do I need to do anything special for Composer or phpcs inside Site Shell? No — composer and vendor\bin\phpcs work normally in LocalWP CMD Site Shell. Navigate to your plugin folder first, then run composer commands:
cd E:\path\to\your-plugin
composer install
composer phpcs
Errors you can safely ignore
If you briefly switched LocalWP Site Shell to Git Bash and ran WP-CLI, you may have seen a wall of warnings like these:
Warning: PHP Startup: Unable to load dynamic library 'php_curl.dll'
Warning: PHP Startup: Unable to load dynamic library 'php_mysqli.dll'
Warning: PHP Startup: Unable to load dynamic library 'php_openssl.dll'
Warning: PHP Startup: imagick: Unable to initialize module
These are Git Bash loading the wrong PHP. Switch back to CMD Site Shell and they disappear. They don’t affect your site, your database, or your plugin code.
Tested on: Windows 11, LocalWP 9.x, PHP 8.4.10, MySQL 8.0.35, WP-CLI 2.12.0, WordPress 6.9. Active troubleshooting time: approximately 2 hours. Tools used: LocalWP Site Shell (CMD), AdminNeo, WP-CLI, Git Bash (tested and ruled out).