The WordPress safety net
you only notice when you need it

What core gives you

When a plugin or theme triggers a fatal error on an admin page, WordPress doesn't just show the "There has been a critical error on this website" page and give up. It also:

1. Notes which extension caused the crash.
2. Generates a one-time recovery link (a URL with rm_token and rm_key params).
3. Emails that link to the site's admin email.
4. When you click the emailed link, WordPress validates the key, drops a recovery cookie, asks you for your password one more time, and finally lets you into a special "Recovery Mode" version of wp-admin where the broken plugin or theme has been paused. It's still installed, just skipped on every page load until you say otherwise.

It's a clever design. The pause means you can keep using the rest of the site. The one-time link means an attacker who scraped the email later can't replay it. The extra password gate means a hijacked browser session alone isn't enough to disable security plugins.

But there's one assumption baked in that bites in practice.

What WP Multitool does differently

If you're already logged in as an admin when the fatal happens, WP Multitool's drop-in (wp-content/fatal-error-handler.php) catches the crash before WordPress emails anything. It:

1. Generates the same Recovery Mode URL core would have emailed. Same rm_token and rm_key, same machinery, same security model.
2. Redirects your browser to it directly. No inbox detour.
3. Then steps out of the way and lets core handle the rest - validate key, set cookie, ask for password, drop you into Recovery Mode.

That's the entire change. We don't replace Recovery Mode. We don't reinvent the security gate. We skip the email leg of the chain when it's pointless, because you're literally already at the keyboard.

The sudo gate (and why we don't kill it)

You're going to enter your password one more time during this flow. We deliberately left that step in place.

Recovery Mode lets you disable any plugin or theme, see file paths and stack traces, and inspect a half-broken site. It's a privileged context, like sudo. WordPress wants one fresh credential confirmation before granting it. Three good reasons for that:

• Cookie-only sessions aren't enough. If your browser session was hijacked and the attacker triggered a fatal to get into Recovery Mode (where they could disable Wordfence), a password gate stops them.
• The recovery link can leak. Even if you skip the email like we do, the URL might still end up in browser history, a reverse proxy log, a screen share recording. The password requirement makes that URL useless without the credential.
• The recovery key is one-time. Combined with the fresh password entry, an attacker who somehow sniffed the URL mid-flight can't replay it.

So even with our shortcut, you'll see the login form once. If you weren't logged in when the crash happened, you'll see it twice - once to be admin again, once to be sudo-admin. That's a WordPress design floor we don't try to dig under.

How to see it work yourself

Install WP Multitool, make sure it's active, then drop a one-line plugin into wp-content/plugins/:

<?php
/** Plugin Name: Crash Test */
add_action( 'admin_init', function () {
    this_function_does_not_exist();
} );

1. Activate it from the Plugins page. The next admin pageload will fatal, and you'll be in Recovery Mode about half a second later.
2. Disable Crash Test from inside Recovery Mode, then click Exit Recovery Mode. Site is back.

No email was sent. No DNS was consulted. (Don't try this on a production site. Obviously.)