Browser-act runs headlessly by default so agents can work without interrupting the user's desktop. Headed mode is still available for local debugging and demos.

Headless mode is the default because it is quiet, resource-efficient, and suitable for background agent work.

Use headed mode only when the user needs to watch or debug the browser:

Standard headless browsers are often detected through signals such as:

Browser-act stealth browsers keep fingerprint masking and headless concealment active together. The goal is to keep background automation quiet without exposing the common signs of headless automation.

Remote assist works even when the browser is headless:

The CLI returns a live URL. A human opens it in any browser, completes the step, and the agent continues in the same session.

Best for background automation and routine tasks. The user does not watch the browser unless remote assist is used.

Best for visual debugging, demos, and local manual steps. It interrupts the desktop and uses more resources.

Best for server work, 2FA, complex CAPTCHA, and human judgment. It requires sharing a temporary handoff link.

Tip: Keep routine agent work headless. Use --headed only when local visual inspection is part of the task.

Use --headed when:

For most agent tasks, keep the browser headless and use remote assist only when needed.

Let a person take over from any device.

Understand the blocking escalation path.

Pick the correct browser type.