What it does: Works out whether Guard Forge is running on a copy of the site, and then stops it acting on the outside world. Lockouts are counted and written to the login log as soft_locked but nobody is shut out; the lockout, new-administrator and file-integrity e-mails stop; and with Pro installed the alerts, the Cloudflare push, auto-lockdown, patch-by-update and the credit-spending AI analysis stop too. How to access: GuardForge > Settings > Staging / development mode. The panel names the signal that decided it and counts what has been held back. Free/PRO: Free, and every Pro module honours it. Notes:

• Three signals, first match wins: the GUARDFORGE_STAGING_MODE constant in wp-config.php, WP_ENVIRONMENT_TYPE being local/development/staging, or a match against the operator’s list of staging host names.
• Nothing that can switch the mode on lives in the database. The host list is matched against the address the site is actually served on, so a staging database copied onto production stops matching the instant the domain changes; a plain “staging mode” checkbox would have the opposite property and is deliberately not shipped.
• Two ways to force production, for a real site mistaken for a copy: the constant set to false, and an “always treat this site as production” setting. Either can only make Guard Forge more protective.
• The free advisory feed is deliberately not suppressed on a copy: it is a public read that carries nothing about the site and changes nothing in the world, and a developer’s copy is exactly where somebody looks before they deploy.