Browser Panels

Overview

A Browser panel is a Chromium pane that lives in your workspace like any other panel. It is meant for looking at something running locally (a dev server, a staging build, a docs site you keep open while an agent works) with enough developer tooling attached that you don't have to leave for a real browser.

It is a different surface from the Portal, which is the sidebar for web AI chats. The Portal is a companion to the whole workspace; a Browser panel is a panel, and it shares the grid with your terminals.

Opening one

The launcher in the toolbar is the primary route: open it and pick Browser. The panel palette (Command-N ⌘N Control-N Ctrl+ N Control-N Ctrl+ N ) still works and lands in the same place. On a fresh profile the browser and dev-preview buttons sit in the launcher's panel tray rather than as standalone toolbar buttons; existing saved layouts are untouched.

Browser is one of the dockable panel kinds, alongside terminals and the file viewer: you can move it to the dock and it keeps a meaningful compact form there rather than vanishing. When it leaves the grid, focus returns to whatever you were last looking at rather than jumping to the first terminal. Like every panel kind it can also be presented as a dialog and promoted back into the grid. See Terminals & Panels.

Sessions and logins

Browser panels no longer share a single Chromium session. Each project gets its own persist:browser-<project> partition, created lazily the first time a panel attaches, so cookies, localStorage and IndexedDB for a site like localhost:3000 (or a forge you signed into) belong to that project and do not bleed into the next one. Two projects can be signed into the same app as different users without fighting over one cookie jar.

Dev previews are partitioned more narrowly still, per project, worktree and panel; the Portal keeps its own single session. Every one of these partitions is locked down to the same untrusted permission set as it is created: camera, microphone, geolocation and the rest are denied.

Toolbar

• Back / Forward: sourced from Chromium's own navigation history, so the tooltips name the page you would land on rather than guessing from a local stack
• Reload: Shift+click for a hard reload that bypasses the HTTP cache. The tooltip says so
• Zoom out / reset / zoom in: adjusts page zoom for this panel
• Address bar: type a URL to navigate, with a history dropdown described below
• Copy URL: copies the current page URL
• Screenshot (camera icon): captures the viewport as a PNG and copies it to the clipboard
• DevTools (code icon): opens Chromium DevTools for the panel in a separate window
• Open in browser: hands the current URL to your system's default browser

There is no keyboard shortcut bound to hard reload by default; the same action is in the command palette as Hard Reload Browser (browser.hardReload), so you can bind it yourself in Keyboard Shortcuts.

Address bar and history

Focus the address bar and a dropdown opens with up to five suggestions, ranked by frecency: visit count weighted by how recently you were last there, in buckets from 4 days out to 90. Each row shows the page favicon, then the title and URL. Typing filters by substring against either.

ArrowDown and ArrowUp move through suggestions, Enter navigates to the highlighted one, Escape dismisses the dropdown. Hover a row and a small × appears at its right edge to remove that entry; from the keyboard, Shift+Delete or Shift+Backspace removes the highlighted row, and a live region announces the removal.

History is per project, capped at 500 entries, and entries older than 90 days age out. Favicons come from the page's own favicon events as you navigate, debounced and stored with the entry; an inline data: favicon larger than 8 KiB is dropped to keep the store small, and that row falls back to a globe icon. The unfocused address bar shows only a scheme indicator (a lock for https, a globe for http), not a live page favicon.

Host approval

The address bar accepts any http: or https: URL, but a host that isn't obviously local is confirmed before it loads. Navigate somewhere new and a banner appears across the top of the panel: "Allow browser panel to load hostname?" with an Allow button and a dismiss ×. Allow it and the navigation proceeds, and the hostname is saved to this project's approved hosts so you aren't asked again.

Some hosts never prompt:

• localhost, 127.0.0.1, ::1
• Any host under .localhost, .test, .local, or .internal
• Loopback, RFC 1918 private, link-local and IPv6 unique-local addresses: 10.x, 172.16–172.31.x, 192.168.x, 169.254.x, fc00::/7
• 0.0.0.0, which is rewritten to localhost before any check runs

Everything else prompts: public hostnames and IPs, bare hostnames with no dot, and host.docker.internal. That last one is matched as a string rather than resolved, so even though it usually points at your loopback interface it still goes through approval once. Credentials embedded in a URL are stripped before it is used.

Approved hostnames are stored in your project's local-scoped settings under browserAllowedHosts. They are never written to .daintree/settings.json, so they aren't committed to git or shared with your team. The file lives outside the project directory, in Daintree's per-user data folder:

Find in page

Press Command-F ⌘F Control-F Ctrl+ F Control-F Ctrl+ F to open the find bar in the top-right of the webview. It has a search input, a match counter ("3 / 12", or "No results"), a Match case (Aa) toggle, and previous/next buttons. The search runs as you type, and the shortcut works even when the page itself has keyboard focus.

View full size:

Dev Preview uses the same find bar, and the shortcuts are identical there.

Cross-origin navigation

Browser panels follow http: and https: links to external domains once the host is approved, which is what makes OAuth and OIDC flows work: a localhost app can redirect through an external identity provider and back again. If a navigation is blocked (a non-HTTP scheme, for example), a banner names the blocked URL and offers Open in External Browser. It auto-dismisses after 10 seconds, or clears on the next successful navigation. If handing the URL to the system browser fails, the banner says so and offers a retry.

JavaScript dialogs

When a page calls alert(), confirm() or prompt(), Daintree renders it as a styled in-app modal rather than an OS-level dialog, which keeps focus inside the panel and avoids blocking the main process.

• Alert: the message with an OK button. Escape also dismisses it
• Confirm: Cancel and OK. Enter confirms, Escape cancels
• Prompt: a pre-filled text input alongside Cancel and OK

Several dialogs arriving at once are queued and shown one at a time, and focus returns to whatever opened the modal session once the queue drains. If the page navigates away or its renderer crashes, queued dialogs are dropped rather than left on screen: the page context behind them is gone, so they could never receive a meaningful answer.

When the page misbehaves

If the panel's renderer process dies, a Page process crashed banner names the reason and exit code and offers Reload. If the page stops responding (usually a long-running script), a Page not responding banner appears with the same reload escape. Both are dismissible, and neither takes the panel down with it.

Agent and MCP control

Agents and external MCP clients can drive a Browser panel within the usual capability tiers:

• Action tier: browser.navigate and browser.openUrl to move a panel, and browser.captureScreenshot to get back real image bytes (pixels, not markup) when what a page looks like is the question. An agent's capture returns the image to the caller without touching your clipboard; your own capture still copies
• Workbench tier: browser.getConsoleMessages, which reads captured console output from a dev preview panel and reports an explicit error if pointed at anything else

Beyond those, the panel's own controls (back, forward, reload, hard reload, zoom, copy URL, DevTools, console toggle, open external) exist as actions so they can be bound to keys or driven from the command palette.