The warm browser & the visible window

browserlane drives a real Chrome window — by default, one you can see.

Visible by default

When you run a browser command, bl opens Chrome for Testing in a visible, maximized window and performs the action there. This is deliberate: watching automation happen makes it far easier to understand and debug than working from logs alone.

Browserlane keeps Chrome warm automatically

Launching Chrome takes a moment. If every bl command had to start a fresh browser, a sequence of commands would be slow. Browserlane solves this with a warm background runtime it manages for you: your first browser command launches a background process that keeps Chrome running, and every later command attaches to the already-warm browser and returns in well under a second.

bl open https://example.com   # first command launches the warm background browser
bl map                        # instant — reuses it
bl click @e1                  # instant — reuses it

There is nothing to start, check, or stop by hand — the background process starts on demand and shuts itself down after a period of inactivity.

Sessions vs. the warm browser

The warm background runtime is about keeping the browser ready across commands. A session is the browser connection itself. bl start is the explicit way to open (or connect) that connection — bare bl start launches a local browser, while bl start <ws-url> connects to a remote BiDi endpoint — and bl stop closes it while the shared browser stays warm for the next command. See Sessions, storage & auth for the full lifecycle and remote-connect flags.

Related

• Your first automation (CLI).
• Sessions, storage & auth.