The Browser screen
What the Browser screen offers today, how tabs, address bar and settings are organized, and what is not part of it yet.
Browser is one of a project’s four screens, alongside Canvas, Chat and Terminal. It is a real browser inside the app: the page you open there is rendered, not downloaded for reading.
What the screen has
- Tab bar — browser tabs, with close, duplicate, pin and open-in-system-browser.
- Toolbar — back, forward, reload and the address bar.
- Device group — viewport size presets to test the page at other dimensions.
- Downloads strip — tracking of downloads in progress and completed.
- Three-dot menu — profiles, profile creation, cookie import, viewport size and a shortcut to the Browser settings.
Tabs
Each tab is a page. The actions live in the tab’s context menu:
- Duplicate — opens another tab on the same page.
- Pin — protects the tab from accidental closing.
- Close and close the tabs to the right.
- Open in the system browser — when you want the page outside the app.
New blank tabs show the new-tab label; the address bar is the starting point.
The address bar
The bar accepts address or search:
- An address takes you straight to the page.
- Anything else becomes a search on the engine configured in settings.
- The bar suggests destinations as you type.
- The search engine and the page zoom level are your choices, made in the Browser settings. One of the supported engines requires you to provide your account’s session link.
A browser tab in a Canvas card
The same page can be addressed from two places: the Browser screen and a browser card on the Canvas. When a card references the tab, the tab exists in that card — with its own subtitle and loading state. Automation commands can target the card, and in that case the target is the card’s workspace, not the one from the directory you called from.
Browser settings
The settings live in Settings → Browser and are also reachable from the three-dot menu. They split into three blocks:
| Block | What it configures |
|---|---|
| Preview | Home page, whether links open inside the app, search engine, page zoom and the localhost preference per workspace |
| Logins and profiles | Session profiles, login import, and what each profile stores |
| Agent in the browser | Whether the agent may use the browser, and the requirements that appear when that option is on |
The agent block only shows the requirements when the option is on. The profile host selector only appears when there is more than one host.
What is not part of this screen today
This is the part that matters most for not creating the wrong expectation:
- There is no automatic preview of your app. The surface that offered to turn on the project’s app and announce “your app just changed” is off in the installed app. Without it, the Browser screen is the browser: the empty state asks you to open a page, and there is no offer to turn the project on by itself.
- Do not count on automatic development-server detection: it is part of the same disabled surface.
- There are no browser developer tools in the installed app. The button and the menu item that open the inspector exist only in development builds — see Limits of the published build.
- There is no phone remote control in the installed app. The gesture that hands the tab’s control to a mobile device is not an available path.