VM Debug Protection

The vmDebugProtection option adds anti-debugging measures to the VM runtime, making it significantly harder to reverse-engineer your protected code. How each detection reacts is set by the debugger, automation, and sandbox categories of vmDefenseReaction.

With browserEnvironment.hosting set to 'remote' (v7.14.1+), Debug Protection also binds the build to being served from a remote host: a copy served from a local development host is treated as a runtime-environment mismatch, and the automation defenses react.

These defenses also act against your own agents, automation, and debuggers. They may stop execution, throw unrelated errors, or produce incorrect results. Use a separate testing build for functional tests; Testing and CI shows the options that build overrides.

Inspector detection

From obfuscator 8.0.0, vmDebugProtection accepts an object as well as a boolean. Passing an object keeps Debug Protection on while relaxing a single detector:

inspectorDetection (default on) detects and reacts to an attached Chrome DevTools Protocol inspector or an active debugger. Opening the browser's developer tools attaches such a session, so an open inspector is detected and reacted to. Keep it on for production; turn it off only if your users legitimately open developer tools. In the dashboard this is the Inspector Detection sub-switch under VM Debug Protection (v8.0.0+), which appears once Debug Protection is on.

Automation frameworks. With inspectorDetection on (the default), driving the protected page with a CDP-based tool (Puppeteer, Playwright, Selenium/ChromeDriver) is detected as an attached inspector. vmDebugProtection: { inspectorDetection: false } turns off only the inspector detector; Debug Protection's automation detector can still react to a driven browser. For automated test builds, follow Testing and CI, which disables vmDebugProtection and vmSelfDefending.

Content Security Policy

If your Content Security Policy prohibits dynamic evaluation (no unsafe-eval), use the browser-no-eval target and validate the output under that policy. This target uses a fallback for checks that otherwise rely on dynamic evaluation. The same applies to browser extensions with a restrictive CSP: use browser-no-eval for best compatibility.