If you’ve ever run a simple WP-CLI command like:
|
1 2 |
wp plugin list |
…and been greeted with a scary-looking warning and a long backtrace, you’re not alone:
Warning: Some code is trying to do a URL redirect…
In most cases, nothing is “broken” in WordPress itself. What’s happening is that a plugin is triggering redirect logic during WordPress bootstrap—something that makes sense in a browser request, but not in a CLI context.
This article explains what’s going on, why WP-CLI complains, and a few clean ways to fix it.
What the warning actually means
WP-CLI loads WordPress (including plugins) so it can run commands with full access to your site’s environment. During that load process, WP-CLI detects calls like:
wp_redirect()wp_safe_redirect()
When those are executed while WP-CLI is bootstrapping WordPress, WP-CLI prints a warning and includes a backtrace to show which plugin/theme triggered the redirect.
In the example backtrace, the redirect was triggered by the Change WP Admin Login plugin (or similarly named code) inside its wp_loaded() handler.
That plugin likely redirects requests that hit /wp-admin/ or /wp-login.php, which is great for security—but WP-CLI isn’t a browser and doesn’t “follow redirects,” so WP-CLI flags it.
The best fix depends on what you’re trying to do
Option 1: Run WP-CLI without loading plugins/themes (fastest + safest)
For commands that don’t need plugins or theme code (like listing plugins), you can skip them:
|
1 2 |
wp plugin list --skip-plugins --skip-themes |
This avoids executing any plugin redirect logic at all.
Use this when:
You’re doing maintenance commands and don’t need plugin/theme behavior.
Option 2: Skip only the plugin causing the redirect
If you want other plugins loaded, but not the one causing trouble:
|
1 2 |
wp plugin list --skip-plugins=change-wp-admin-login |
Use this when:
You rely on other plugin code during CLI operations, but one plugin is noisy.
Option 3: Deactivate the plugin (without loading plugins/themes)
If the plugin is misbehaving or you’re troubleshooting, you can deactivate it cleanly:
|
1 2 |
wp plugin deactivate change-wp-admin-login --skip-plugins --skip-themes |
Then rerun your normal command:
|
1 2 |
wp plugin list |
Use this when:
You’re investigating site behavior or need to temporarily remove the plugin.
A more permanent solution: teach the plugin to “do nothing” in WP-CLI
Redirect logic should never run during CLI execution. The clean pattern is:
|
1 2 3 4 |
if ( defined('WP_CLI') && WP_CLI ) { return; } |
If you control the plugin (or can submit a patch upstream), place that check early in the function that triggers the redirect (often inside wp_loaded() or similar hooks).
Benefit: No more warnings, no need to remember special flags.
Downside: Editing plugin files directly can be overwritten by updates.
The update-safe fix: add a MU-plugin to disable redirect behavior in WP-CLI
MU-plugins (“must-use” plugins) load before normal plugins and are not affected by standard plugin updates.
- Create a directory if it doesn’t exist:
|
1 2 |
mkdir -p wp-content/mu-plugins |
- Create this file:
wp-content/mu-plugins/disable-admin-login-redirects-in-wpcli.php
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
<?php /** * Disable admin-login redirect behavior under WP-CLI. * Adjust the hook removal if your plugin uses a different class/method. */ if ( defined('WP_CLI') && WP_CLI ) { add_action('plugins_loaded', function () { // Example removal pattern when a plugin hooks into wp_loaded(). // This must match the exact class + method used by the plugin. if ( class_exists('AIO_Login\\Change_WP_Admin_Login\\Change_WP_Admin_Login') ) { // If the plugin has a singleton, use it. Otherwise, adapt accordingly. if ( method_exists('AIO_Login\\Change_WP_Admin_Login\\Change_WP_Admin_Login', 'get_instance') ) { $instance = AIO_Login\Change_WP_Admin_Login\Change_WP_Admin_Login::get_instance(); remove_action('wp_loaded', [ $instance, 'wp_loaded' ]); } } }, 20); } |
Notes:
- The class/method names must match what the plugin actually uses.
- Your WP-CLI backtrace shows you the exact file and method involved—use that to tailor the removal.
- This approach is update-safe because it doesn’t edit the plugin.
Troubleshooting tips
“The warning still happens”
Try running with full skipping to confirm it’s plugin-driven:
|
1 2 |
wp plugin list --skip-plugins --skip-themes |
If that eliminates the warning, your MU-plugin hook removal likely needs adjustment (wrong class name, wrong method name, wrong hook priority, etc.).
“I need plugins loaded for this command”
Use a targeted skip instead:
|
1 2 |
wp <command> --skip-plugins=change-wp-admin-login |
“Which plugin is doing it?”
The backtrace tells you. Look for the first path under wp-content/plugins/... and the method name being executed.
Recommended approach (practical guidance)
- For one-off admin tasks: use
--skip-plugins --skip-themes. - For regular WP-CLI usage on the same server: use
--skip-plugins=<plugin-slug>or a shell alias. - For a clean long-term environment: add the
WP_CLIguard in the plugin, or use a MU-plugin workaround.
Takeaway
This warning usually means: a plugin is running browser-only behavior (redirects) during WP-CLI boot. It’s common with security/login-hardening plugins and is typically harmless—but it’s noisy and can interfere with automation.
With the options above, you can either:
- run WP-CLI in a “minimal mode,”
- skip only the problematic plugin, or
- permanently suppress redirect behavior during CLI in an update-safe way.
If you paste the exact plugin slug from wp plugin list --skip-plugins --skip-themes (and/or the specific class/method names from the backtrace), you can tailor the MU-plugin snippet to match your site exactly.
