Concepts

Browser

LoopCode opens your app in a real browser, clicks through it, reads the page and takes screenshots to check its work — in the desktop app's built-in browser or a Chrome the CLI drives.

#What LoopCode does with a browser

With a browser, LoopCode can check web work the way you would: open the page, click and type, read what is on screen, watch the console, run a script in the page, and take a screenshot to look at the result. When a change touches the UI of a web project, a browser check is part of its proof of done.

Start the dev server, log in as the demo user, and check that the invoices table
sorts by date. Take a screenshot of the sorted table.

#In the desktop app

The Browser tab is a real Chromium browser with tabs, an address bar and history. It keeps one saved profile, so your sign-ins and site data stay from one launch to the next — sign in to your app once, and LoopCode can work with it signed in.

• You browse in it like any browser; LoopCode drives the tab in front.
• File → New Browser Tab (⌘ T), View → Show Browser (⌘ ⇧ B).
• Popups open as tabs; downloads and the right-click menu work as usual.

#In the terminal

The CLI drives a real Chrome or Chromium installed on your computer, with its own profile for LoopCode.

By default the browser is visible, and headless in CI or on Linux without a display. loopcode doctor tells you whether a browser was found. When LoopCode runs as root (in a container, for example), it starts Chrome with its sandbox off, as Playwright and Puppeteer do.

#Permissions

Browser actions go through the same permission modes and rules as everything else. Rules can match a browser action:

{ "permissions": { "ask": ["Browser(action:open)"] } }

WebFetch, the tool for reading a page as text without a browser, refuses private, loopback and cloud-metadata addresses.

#Browser automation through MCP

You can also connect the Playwright MCP server for browser automation:

loopcode mcp add playwright -- npx -y @playwright/mcp@latest