Bronom

Bronom is a visible, multi-tab Electron browser that exposes its live tabs to AI clients through MCP. It is deliberately not headless and is not tied to the lifetime of an AI session.

Project website: https://netroforge.github.io/bronom/

What it keeps

• Cookies, local storage, IndexedDB, service workers, cache, and login sessions use Electron's persistent persist:bronom partition.

• Open tabs and the active tab are restored from tabs.json in Electron's user-data directory.

• Per-tab and all-tab human-interaction locks are restored from tabs.json as well.

• Appearance, search-engine, and other application settings are restored from settings.json in the same profile.

• Allowed and blocked website permissions are restored from site-permissions.json in the same profile.

• Window position, size, monitor, maximized state, and fullscreen state are restored. If that monitor is disconnected, the window is centered on the current primary display.

• Closing the window hides it by default. The Electron process and MCP endpoint keep running; click the tray icon to open its menu and choose Show Bronom or Quit. Disable Hide in tray when closing in Settings to make the window close button quit Bronom instead.

• A second launch focuses the existing instance instead of starting a competing browser profile.

Related MCP server: Browser Agent MCP Server

Appearance

Open Settings from the gear button in the top strip. Bronom includes four application themes:

• System follows the operating system's light or dark appearance as it changes.

• Light for a bright, neutral browser shell.

• Dark for a low-glare browser shell.

• Cyberpunk for a neon cyan and magenta browser shell.

The selected theme is applied immediately and survives application restarts. System mode keeps Bronom's renderer, native menus, and window background aligned with Electron's current operating-system theme. A fixed theme changes Bronom's controls and native color preference without injecting styles into websites. The same dialog includes separate Search engine, MCP security, Privacy & data, Site permissions, Passwords, and Updates sections.

Choose the default search engine

Open Settings → Search engine to choose Google, DuckDuckGo, Bing, Brave Search, or Startpage. Plain text submitted from the address bar and browser_navigate uses the selected provider immediately; recognizable addresses and explicit URL schemes continue to navigate directly. The choice is stored in the local Bronom profile. Local tab, bookmark, and history suggestions remain on-device and do not send keystrokes to any provider.

Clear browsing data safely

Open Settings → Privacy & data to review local history-page and visit counts, cookie count, and HTTP cache size. Select browsing history, cookies and site data, cached images and files, or any combination once, then either clear one website from the searchable list or use Clear all websites… for the whole profile. The Settings-owned website list never changes its target when another browser tab gains focus. Cookies and site data are off by default because removing them can sign you out; history and cache are selected by default.

The inventory combines origins from local history, cookies, open tabs, bookmarks, saved accounts, and permission decisions; storage-only origins that Chromium does not expose as an index may not appear until they are known through one of those sources. Each website row shows available cookies and history plus retained bookmarks, accounts, permissions, and open tabs.

For the current page, click the controls icon at the left of the address. The compact Site controls panel shows cookies available to that address, exact-origin history, and saved permission decisions. Change or reset a permission in place, open all site settings, or jump to Privacy & data already filtered to that explicit website. Opening Privacy normally resets the filter and shows the complete list.

Website-scoped history matches the exact origin; storage and cache use Chromium's origin matching; cookies may also be removed from related subdomains because browsers store them at domain boundaries. Clearing site data covers cookies, local storage, IndexedDB, file-system data, service workers, offline caches, Web SQL, and background fetch data. Bronom temporarily rejects new MCP commands and waits for active commands to finish while the operation runs, then restores the previous pause state. Open pages are deliberately not reloaded, so unsaved page state is not discarded; reload a page when you want it to observe the cleared session. Bookmarks, downloaded files, the encrypted password vault, site-permission decisions, settings, and open tabs are never removed by this action.

Site permissions

When a website requests access such as location, notifications, clipboard, camera, or microphone, Bronom asks before granting it and remembers the Allow or Deny decision for that exact website origin. Open Settings → Site permissions to change a saved decision, forget one so Bronom asks again, or reset the section to clear all saved decisions.

Updates

Automatic update checks are enabled by default. Packaged builds check the public GitHub release feed shortly after startup unless you disable Check for updates on startup. Bronom never downloads an update silently: an in-app notification shows the available version and release notes, then asks you to Download update and Install and restart.

On Linux, Bronom waits for the old single-instance process to finish its bounded profile and MCP shutdown before launching the newly installed DEB, RPM, or AppImage. This prevents an immediate second update prompt from the still-running old binary during consecutive releases.

You can also check manually from Settings, the Bronom application menu, or the tray menu. Update preferences are stored in the persistent profile. Development builds do not contact the release feed; set BRONOM_DISABLE_AUTO_UPDATE=1 to disable checks for a packaged launch as well.

Bronom Home

The dedicated Home application button sits outside the browser tab list and opens Bronom Home, an internal dashboard that stays inside the persistent browser partition. It is app navigation, not a reserved browser tab. While Home is active, Bronom keeps the top strip for switching to open websites but removes the website-only Back, Forward, address, and page-action row, giving the dashboard the reclaimed space. Application-wide Search tabs, Downloads, History, Bronom lock, MCP, and Settings controls remain in the same top-strip positions on Home and websites; only page-specific navigation and tools appear beside the address. Bronom keeps Home as a singleton: clicking the button focuses the existing Home page or recreates it if needed. Regular new tabs remain blank. Home provides:

• Copy-ready setup instructions for Codex, Claude Code, Cursor, VS Code/GitHub Copilot, and generic Streamable HTTP clients.

• A live list of active requests and recently seen MCP clients.

• The current browser tool catalog, grouped by session, navigation, interaction, and inspection.

• A privacy-safe activity dashboard with recent tab actions, duration, outcome, and per-launch impact totals. It records no URLs, selectors, typed text, screenshots, or page content.

• The local MCP endpoint and authentication guidance.

Regular websites, including https://google.com, can be opened from the address bar, a new-tab request with a URL, or browser_navigate.

Right-click a website tab to create a named group, move the tab into any existing group, remove it from its current group, or rename the group. Humans and agents use the same persistent groups: each group has one public ID, name, color rail, and contiguous tab cluster. Group IDs coordinate ownership; they are not secrets.

Pause agents instantly

Use the pause button beside MCP ready to reject new MCP commands immediately while keeping Bronom, its tabs, logins, and browser profile open. Resume from the same control when you are ready. This runtime safety switch is intentionally separate from MCP authentication and resets when Bronom restarts.

Saved passwords

When you manually submit a website password form, Bronom can ask whether to save or update that login. Passwords are encrypted asynchronously by the operating system through macOS Keychain, Windows DPAPI, or a supported Linux secret store. Bronom refuses to enable password saving when Linux would fall back to Electron's unprotected basic_text backend.

Saved-account metadata can be reviewed or removed under Settings → Passwords. Bronom never exposes stored passwords through its preload API, Settings, Home dashboard, or MCP tools. Use the password button in the toolbar to fill an account for the active website. Bronom pauses new MCP commands before decrypting and filling, waits for active requests to finish, and remains paused until you explicitly resume agents.

Prevent accidental human interaction

Use Tab beside the address bar to lock the current tab, or Bronom in the tab strip to lock the entire app. Both block human mouse, wheel, context-menu, and keyboard input. A full-app lock leaves only its own unlock button active, so it is still easy to release. MCP inspection and interaction continue to work while human input is locked.

Right-click webpage actions

Right-click an unlocked website to use a native context menu. Links can open in a background tab, be copied, or downloaded; images can be copied, opened, or saved; text fields expose spelling suggestions and standard editing commands; selections can be copied; and every page includes Back, Forward, Reload, Reload Without Cache, Copy Page Address, and Inspect. The native View menu and Ctrl/Cmd+R now reload the active website rather than Bronom's application shell; use Ctrl/Cmd+Shift+R when debugging requires a fresh network load. Download actions use Bronom's configured collision-safe download directory. Context menus remain completely suppressed while the tab or all of Bronom is human-interaction locked.

Inspect current-site storage

Use the database button in the website toolbar to inspect, filter, add, edit, or delete the active tab's local storage, session storage, and cookies. Local storage and cookies are shared by origin across Bronom tab groups; session storage belongs only to the selected tab. Bronom displays sizes, bounds long previews, and keeps HttpOnly cookie values protected from both the human panel and MCP storage tools.

Get help from the application menu

Use the native Help menu beside Bronom, Edit, and View below the window title. It follows Textonom's familiar structure: Keyboard Shortcuts, About Bronom, Support Bronom, GitHub Repository, and Check for Updates. Because the menu is owned by the operating system rather than drawn inside the browser toolbar, it remains visible above Home, websites, and native page views on every tab.

Debug a website with Chromium Developer Tools

Open View → Developer Tools, use F12, Ctrl+Shift+I on Linux or Windows, or Cmd+Option+I on macOS to open detached Chromium Developer Tools for the active website tab. The right-click Inspect action opens the same per-tab tools and selects the element under the pointer. Locking the tab or all of Bronom closes its Developer Tools so the human-interaction lock remains effective.

Electron permits only one debugger connection to a website at a time. MCP actions that depend on the Chrome DevTools Protocol therefore ask you to close Developer Tools first; regular page actions and Bronom's bounded console and network records remain available. Closing Developer Tools restores those debugger-backed MCP actions immediately.

Agents can use browser_emulate to reproduce failures under offline, Slow 3G, Slow 4G, or Fast 4G network conditions; slow the CPU from 1–20×; set light/dark and reduced-motion preferences; override the user agent; or apply a mobile/desktop viewport with DPR, touch, and orientation. The same tool can supply test coordinates and extra request headers for location-aware or server-variant debugging. A website still needs its normal Bronom geolocation permission. Header values are applied inside the website tab but only their names appear in tab state or the trusted shell. Overrides apply only to the chosen tab, survive navigation and reload, and can be inspected or reset through the same tool. Bronom marks the tab with a speed icon and shows the active condition beside its address; click that pill to restore normal conditions immediately.

Copy an element for an agent

Open a website and click the crosshair button at the right of the address bar. Bronom highlights DOM elements as you move over the page. Click one to copy an agent-ready description containing the page, a CSS selector, safe element attributes, visible text, and viewport bounds. Press Escape or click the crosshair again to cancel. Form values and inline event handlers are never included.

Find in a page

Press Ctrl+F on Linux or Windows, Cmd+F on macOS, or use the find button beside the address bar. Bronom uses Chromium's native page search to highlight matches and show the current result count. Press Enter or Shift+Enter to move between matches, or Escape to close the bar and clear the search selection.

Browser keyboard shortcuts

Bronom supports the standard browser shortcuts from either its shell or the active website: Ctrl/Cmd+L focuses the address bar, Ctrl/Cmd+T opens a tab, Ctrl/Cmd+W closes the active tab, and Ctrl/Cmd+Shift+T reopens the most recently closed website tab. Ctrl/Cmd+Shift+A searches open and recently closed website tabs. Ctrl/Cmd+D saves or removes the current website bookmark. Ctrl+H on Linux/Windows or Cmd+Y on macOS opens browsing history. Ctrl/Cmd+Shift+Delete opens Privacy & data settings. Ctrl+Tab and Ctrl+Shift+Tab cycle through tabs. F12, Ctrl+Shift+I, or Cmd+Option+I toggles Developer Tools for the active website. Closed-tab recovery stays in memory for the current Bronom launch and is separate from persistent browsing history.

Search and restore tabs

Use the fixed tab-search button or press Ctrl/Cmd+Shift+A from Bronom or any active website. Search matches titles and addresses across both open tabs and the bounded recently closed stack. Use Up/Down and Enter to switch to an open page or restore any matching closed page without leaving the keyboard; pin, unpin, and close open entries directly from the accessible floating panel. Recently closed entries retain only title, address, pin state, and close time for the current launch. Home remains application navigation and is intentionally excluded from website-tab results. This keeps active pages discoverable when the 50-tab strip overflows and makes recovery visible without requiring a shortcut.

Find local pages from the address bar

Start typing a title or address to match open tabs, bookmarks, and browsing history in one dropdown. Open tabs are ranked first and switch directly instead of loading a duplicate; bookmarks follow, then recent history. Use Up/Down and Enter or click a result. Type @tabs, @bookmarks, or @history followed by optional keywords to limit the local source. Matching and ranking happen entirely inside Bronom: focus and keystrokes are not sent to a suggestion service. If you submit text that is not a local result or recognizable address, Bronom sends it to the provider selected under Settings → Search engine only after you press Enter.

Pin important tabs

Right-click a website tab and choose Pin Tab, or use the pin control in open-tab search. Pinned tabs stay compact at the left of regular website tabs. Drag tabs along the strip to arrange them; pinned tabs can be reordered among pinned tabs and regular tabs among regular tabs, preserving the compact left boundary. The right-click menu also offers Move Tab Left and Move Tab Right for an accessible non-drag alternative. Custom order and pinned state are stored with the profile and restored after an application restart, while closed-tab recovery keeps the pin state during the current launch. Unpin from the same native menu or search panel. Home remains separate application navigation and cannot be pinned or reordered.

The same native tab menu can reload, mute, or duplicate a tab while preserving its Back/Forward history. It can close duplicate tabs, other unpinned tabs, or unpinned tabs to the right without touching pinned tabs. Every closed website remains recoverable with Reopen Closed Tab or Ctrl/Cmd+Shift+T during the current launch, including a full 50-tab bulk close.

Save local bookmarks

Press Ctrl/Cmd+D or use the star beside the address bar to save the current HTTP or HTTPS page. Open the bookmarks panel to search, rename, remove, or open saved pages. Bookmarks are kept locally in the Bronom profile with atomic writes, duplicate addresses update the existing entry, and non-web URL schemes are rejected. Agents can manage the same collection with browser_bookmarks.

Review local browsing history

Press Ctrl+H on Linux/Windows, Cmd+Y on macOS, or use the history button to search recently visited pages, reopen one, remove an individual entry, or clear the collection. Bronom stores one recency entry per normalized HTTP or HTTPS address, counts repeat visits, removes URL credentials and fragments, and automatically drops visits older than 90 days. Home, about:, data:, and other internal pages are never recorded, and restoring a saved tab does not count as a new visit. History stays in the local profile with atomic writes; clearing it does not remove cookies, passwords, bookmarks, or downloaded files. Agents can use browser_visit_history to list, search, reopen, remove, or clear the same collection.

Identify and mute tabs

Website tabs display their real favicon after Bronom safely normalizes it into a local 32px PNG; remote favicon URLs are never loaded inside the trusted shell. When a tab emits audio, a speaker appears beside its title. Click it to mute or unmute only that tab without changing sound permissions for the entire site. Agents can use browser_audio, and browser_tabs reports each tab's audible and muted state.

Recover a failed page

When a website cannot be reached, its renderer crashes, or it stops responding, Bronom shows a compact diagnostic row beneath the address bar instead of leaving an unexplained blank tab. Try again retries the exact failed address or reloads a crashed page in a fresh renderer process. The row expands the shell so it never covers website content, disappears after recovery, and includes the underlying Chromium error or process-exit reason when available. Agents receive the same structured pageProblem details through browser_tabs and can retry with browser_history using reload or reload-ignoring-cache.

Change the MCP port

Open Settings → MCP security, enter an available port from 1024 through 65535, and choose Apply port. Bronom starts the replacement listener before stopping the old one; if the requested port is unavailable, the current MCP endpoint keeps running and the saved setting is unchanged. Connected clients must be updated to the new endpoint after a successful move.

Save a page as PDF

Use the PDF button beside the address bar to save the active page with backgrounds to the configured download directory. Bronom derives a portable filename from the page title and adds a numeric suffix instead of overwriting an existing file. Agents can use browser_pdf_save and optionally choose a portable filename, A4/Letter/Legal paper, or landscape orientation.

Track downloads

Website downloads appear in the toolbar with live byte progress and a recent-item count. Open the download panel to cancel an active transfer, reveal a completed file in its operating-system folder, or clear finished entries. The panel opens when a new download starts, floats over the page without resizing it, and keeps completed, cancelled, and interrupted items in memory for the current Bronom launch. In Settings → Downloads, choose a persistent destination, open it in the operating-system file manager, or ask where to save every new website download. Automatic saves remain collision-safe and never overwrite an existing file. Active transfers keep the destination they started with.

Run

Requirements: Node.js 22+ and a graphical Linux, macOS, or Windows session.

npm install
npm run dev

Development runs use a persistent bronom-dev profile. This keeps development cookies, tabs, storage, and window state across restarts while avoiding the single-instance lock and profile of an installed Bronom build. If an older window appears after upgrading the source, quit it from Bronom → Quit once instead of only closing the window.

For the built application:

npm run build
npm start

To ask an already running development instance to flush its profile and quit cleanly:

node_modules/.bin/electron . --quit

The MCP endpoint is available while the app is running:

http://127.0.0.1:47812/mcp

Health check:

export BRONOM_MCP_TOKEN="$(cat ~/.config/Bronom/mcp-token)"
curl -H "Authorization: Bearer $BRONOM_MCP_TOKEN" http://127.0.0.1:47812/healthz

The exact profile path is shown on Bronom Home. On Linux, the packaged default is ~/.config/Bronom/mcp-token; development builds use ~/.config/bronom-dev/mcp-token. Bronom creates one random token per profile and restricts the token file to the profile owner.

Connect an MCP client

Use a Streamable HTTP MCP configuration and start Bronom before the client connects. A generic JSON configuration looks like:

{
  "mcpServers": {
    "bronom": {
      "url": "http://127.0.0.1:47812/mcp",
      "headers": {
        "Authorization": "Bearer <paste the token shown by Bronom Home>"
      }
    }
  }
}

The exact schema depends on the MCP client; Bronom Home includes separate current instructions for the major coding agents. Disconnecting or closing that client does not close Bronom.

Optional environment variables:

• BRONOM_MCP_PORT: override the saved listen port for the current launch. Without the override, the port can be changed under Settings → MCP security and defaults to 47812 for new profiles.

• BRONOM_MCP_HOST: loopback listen host, default 127.0.0.1. Non-loopback values are rejected.

• BRONOM_MCP_TOKEN: override the generated per-profile token with at least 32 URL-safe characters. While authentication is enabled, every MCP and health request must send Authorization: Bearer <token>.

• BRONOM_DISABLE_MCP_AUTH: start the current launch with MCP authentication disabled. The same setting can be changed immediately under Settings → MCP security. Bronom remains loopback-only, but every local process can then control the profile; use this only on a trusted single-user machine.

• BRONOM_USER_DATA_DIR: use an alternate profile directory instead of the packaged or bronom-dev default. This is primarily useful for isolated integration tests.

• BRONOM_DISABLE_AUTO_UPDATE: set to 1 to disable update checks for the current launch.

• BRONOM_DOWNLOAD_DIR: use this directory as the profile's default instead of the operating system's Downloads directory. A folder explicitly chosen in Settings takes precedence.

MCP tools

• browser_tab_groups

• browser_status, browser_show, browser_tabs

• browser_request_user_attention

• browser_new_tab, browser_select_tab, browser_close_tab, browser_bookmarks, browser_visit_history, browser_site_data, browser_storage

• browser_navigate, browser_history, browser_wait

• browser_snapshot, browser_click, browser_dialog, browser_type, browser_fill_form, browser_press

• browser_select, browser_hover, browser_drag, browser_scroll, browser_file_upload

• browser_resize, browser_emulate, browser_zoom, browser_audio, browser_screenshot, browser_pdf_save, browser_accessibility_audit, browser_performance, browser_memory, browser_console, browser_network, browser_network_request, browser_network_routes, browser_downloads, browser_evaluate

The preferred interaction loop is browser_snapshot → semantic element ref (e1, e2, ...) → browser_click or browser_type. Take a fresh snapshot after navigation or large DOM changes.

Every MCP browser workflow starts with browser_tab_groups. List the visible groups, then either resume the group assigned to the current task or create a clearly named one. Pass that groupId to every other browser tool. New tabs, bookmark/history opens, website popups, duplicated tabs, closed-tab restores, the implicit active tab, and returned browser state all stay inside that group. Bronom rejects a tab ID from a different group, never exposes ungrouped human tabs through browser_tabs or browser_status, and preserves groups and their tabs across restarts. Group IDs are visible workspace identifiers, not secrets or authentication credentials; this is a cooperative agent-ownership contract on top of the profile's bearer-token authentication.

Tab groups isolate control and navigation ownership, not website identity. Every group deliberately shares Bronom's persistent Chromium profile, including cookies, storage, permissions, bookmarks, history, downloads, and cache. The global data tools therefore still affect that shared profile and should be used only when the task requires it.

browser_storage inspects or edits local storage, tab-specific session storage, and non-HttpOnly cookies for one tab inside the caller's group. Lists default to metadata-only; request includeValues or use an explicit get when a bounded value is needed. Results are capped at 200 entries, 16 KiB per returned value, and 128 KiB of values in total; inputs are capped at 256 KiB. HttpOnly cookie values are never returned or edited. Use browser_site_data when the task requires clearing broader origin data such as caches or all cookies and storage.

When a manual step is unavoidable—such as entering credentials, completing a CAPTCHA, approving a device prompt, or pressing a control that cannot be automated—an agent can call browser_request_user_attention with a short reason and optional tab ID. Bronom plays the selected attention cue, pulses its tray icon, and flashes its taskbar entry until the window is focused or the alert is dismissed from the tray menu. The cue can be selected, previewed, or disabled in Settings → Appearance. The pending request is also reported by browser_status. Do not include passwords, tokens, or other secrets in the reason because it is displayed in the operating-system tray.

browser_screenshot returns image content directly to the connected agent, ready to display or copy into its chat. Capture the visible viewport, the full page, one element from the latest snapshot with ref, any unique element with selector, or an exact visible rectangle with clip: { x, y, width, height }. Element targets are scrolled into view and captured at their full page bounds; clip coordinates are viewport-relative and must fit inside the visible page area. PNG remains the lossless default; agents can request JPEG with a quality from 1–100 and bound any result with maxWidth and/or maxHeight while preserving its aspect ratio. For a human-reported issue, use the screenshot-region button in the website toolbar, drag the relevant area, then paste the PNG from the system clipboard into Cursor, Codex, Claude, or another agent chat with Ctrl/Cmd+V. The picker remains usable on a locked tab without unlocking it: its temporary full-page overlay owns the permitted drag, the website receives no click, and normal native input blocking resumes immediately. Compact captures reduce image transfer and model-context cost, and every scope keeps working while Bronom is hidden in the tray. browser_pdf_save writes a rendered PDF to the configured download directory and never silently overwrites an existing file. Console and network histories are bounded to the 500 most recent entries per tab. browser_network returns lightweight metadata with credentials, fragments, and security-related query values removed. Pass one returned ID to browser_network_request to inspect bounded request and response headers and bodies; authorization, cookies, API keys, tokens, passwords, and other named structured secrets are redacted, while binary and multipart bodies are omitted. Chromium keeps only a bounded diagnostic payload buffer, so old or very large response bodies may be unavailable. Website downloads are tracked through MCP, use collision-safe filenames, and never silently overwrite an existing file.

browser_network_routes can temporarily fulfill or abort matching requests in one tab so an agent can reproduce API errors, timeouts, and deterministic response states. Patterns use Chrome wildcard syntax and can be restricted to one HTTP method. Routes are one-shot by default, can be bounded to 100 matches, and are never persisted across app restarts or tab closure. A tab can hold at most 50 routes; each mock body is capped at 512 KiB and its headers are validated and bounded. The trusted toolbar and tab strip show a red route indicator while any interception is active, and the human can clear every route for the current tab in one click. Opening Developer Tools also clears routes because Electron gives DevTools exclusive ownership of the page-debugging transport.

browser_accessibility_audit runs the bundled axe-core engine locally inside one website tab and returns prioritized WCAG violations without uploading the page to an audit service. It checks WCAG A/AA by default, can target one CSS selector, and can instead include AAA, best-practice, or all enabled rules. Agent responses are bounded to 50 rules and 10 affected nodes per rule; they contain selectors and failure summaries, not element HTML or form values. Humans can run the same A/AA audit from the accessibility button beside the website toolbar, review critical and serious findings, open rule guidance, and rerun after a fix. Automated checks cannot prove complete accessibility, so keyboard and assistive-technology testing remain necessary.

browser_performance measures the current local visit with the bundled Google web-vitals collector. It reports LCP, INP, CLS, FCP, and TTFB when the browser has observed them, plus navigation milestones, aggregate resource sizes by type, and bounded long-task totals without returning resource URLs or page markup. The toolbar performance button presents the same report for a human. The collector runs once per page load in an isolated world, stays available across repeated measurements and soft navigations, and does not occupy Electron's single DevTools debugging connection. These results are one local sample—not field data or a 75th-percentile CrUX result—and INP remains unavailable until a qualifying interaction occurs.

browser_memory measures aggregate JavaScript heap usage plus document, frame, DOM-node, event-listener, and layout-object counters for one group tab. Set a runtime baseline, reproduce the same interaction, then measure again with optional forced garbage collection to receive signed deltas. The toolbar memory button exposes the same workflow to a person. A full navigation clears the baseline, and closing the tab discards it; nothing is persisted. Growth is evidence to investigate, not proof of a leak, so repeat the same interaction and compare multiple post-GC samples. Bronom intentionally does not create raw heap snapshots because they can be extremely large and may retain page strings or other sensitive values.

browser_resize applies a persistent per-tab desktop viewport override for responsive testing and can reset it without resizing the application window. browser_emulate adds isolated network, CPU, media-preference, user-agent, mobile/touch viewport, geolocation, and extra-request-header conditions to one tab. Use null to clear only viewport or geolocation, an empty object to clear extraHttpHeaders, omit overrides to inspect state, or reset: true to restore every normal condition. Request-header values are intentionally redacted from returned state. browser_zoom changes page content from 50% to 300% without scaling the Bronom toolbar or Settings. browser_audio mutes one tab without changing site-wide sound permissions. browser_bookmarks lists, adds, renames, removes, or opens locally saved pages. browser_visit_history searches, reopens, removes, or clears the bounded local visit log. browser_site_data inspects one explicit HTTP(S) origin or clears selected cookies-and-storage, cache, and history categories for that origin so agents can reproduce clean-session bugs. It cannot clear the whole profile, does not reload open pages, and never removes bookmarks, passwords, permissions, downloads, or settings. browser_fill_form updates several inputs, text areas, selects, checkboxes, radios, or editable elements in one call.

browser_dialog accepts or dismisses an already-open JavaScript alert or confirm dialog. An agent that knows a click or evaluation will open one can instead provide dialogAction directly to browser_click or browser_evaluate. For a website click that opens window.prompt(), browser_click also accepts promptText. Bronom responds inside the same operation so the page cannot deadlock the tool call. Electron does not implement native prompts, so Bronom installs a prompt response only around that explicit click; all other dialogs remain native and user-visible.

Support Bronom

Bronom is free and open source. The current funding goal is Windows code signing and Apple notarization so new users see fewer security warnings when installing it. Support is always optional; Bronom has no locked features or donation popups.

Security model

• The MCP server binds to loopback by default and rejects non-local browser origins.

• By default, every MCP and health request requires a strong bearer token. Bronom generates and reuses an owner-only token for each browser profile unless a valid BRONOM_MCP_TOKEN override is supplied. Authentication can be explicitly disabled in Settings → MCP security or for launch with BRONOM_DISABLE_MCP_AUTH=1.

• Website tabs have Node.js disabled, context isolation enabled, Chromium sandboxing enabled, and web security enabled.

• New browser windows become managed tabs.

• Unknown site permission requests require explicit confirmation. Bronom remembers each decision per website origin and permission type, and lets you review or revoke it later in Settings.

• Camera, microphone, and file-system grants are never reused: Bronom shows the requested scope and asks again each time.

• browser_evaluate is intentionally powerful: only connect trusted AI clients to this browser profile.

• Saved passwords use OS-backed encryption and can only be filled by a human from the Bronom toolbar. Filling pauses MCP first because any password placed into a page can otherwise be read by page JavaScript or a trusted client using browser_evaluate.

• browser_network_request can return API request and response content to an authenticated client. It redacts named security headers and structured secret fields, bounds text, and omits binary or multipart bodies, but it is a debugging aid rather than a data-loss-prevention boundary. Only connect clients you trust with the visible browser session.

• browser_network_routes can replace or fail website requests in the selected tab. Routes are visible, bounded, temporary, and human-resettable, but a trusted client can still alter what that page receives while they are active.

• Accessibility audits execute the bundled axe-core rules inside the selected website and return bounded selectors and failure summaries. They do not send page content to a third party, but selectors and page addresses still reach the authenticated MCP client.

• Performance reports execute the bundled web-vitals collector locally in an isolated world and return aggregate timings, sizes, and bounded element selectors without resource URLs or markup. Page addresses and metric target selectors still reach the authenticated MCP client.

• browser_file_upload can attach any absolute local file path supplied by a connected client. Only connect clients you trust with local file access.

Testing

Unit tests live in tests/*.test.ts and use Vitest. Real-application integration tests live in tests/integration/*.e2e.ts and use Playwright's Electron API with reusable fixtures from tests/integration/fixtures.ts. Every integration test launches Bronom with an isolated temporary profile and cleans it up afterward. The suite covers the visible shell, tabs, MCP, Home, themes, site permissions, restart persistence, and updater settings without contacting the live release feed. Application, test, preload, website, and build configuration source is TypeScript.

npm test
npm run test:integration
npm run test:integration:dialogs
npm run typecheck
npm run build
npm run build:website
npm run build:unpack
npm run test:package:smoke

On a headless Linux machine, run the already-built integration suite under Xvfb:

xvfb-run --auto-servernum npm run test:integration:run

The CI workflow runs unit tests, the production build, the Playwright Electron suite, a raw Electron dialog test without a competing automation debugger, and the production dependency audit. Pull requests whose branch name contains release- additionally build the complete Linux, macOS, and Windows package sets in a hosted matrix before merge.

GitHub Pages

The English product website is authored in website/ with TypeScript behavior and built by Vite. The dedicated Pages workflow builds it from main, uploads the generated docs/ artifact, and deploys it through GitHub Pages. It resolves platform-specific downloads from the latest public GitHub release only after a user clicks a download card.

Preview the exact production output locally:

npm run build:website
npm run preview:website

Releases

GitHub Actions validates every pull request and every push to main. When package.json changes to a new version on main, the auto-tag workflow creates an annotated v<version> tag and dispatches the release workflow. The initial repository commit is intentionally not auto-tagged.

The release workflow creates one draft release, builds Linux, macOS, and Windows artifacts in parallel from the immutable tag commit, uploads the updater manifests and a hashes.txt SHA-256 manifest, and publishes only after every platform job succeeds. Packaged Bronom builds use those manifests through electron-updater. The workflow can also be dispatched manually for an existing version tag.

Current releases are unsigned community builds: the binaries are not platform code-signed and macOS packages are not Apple-notarized. macOS Gatekeeper and Windows SmartScreen may therefore warn before first launch. Build jobs never receive release-write credentials; the final job publishes the completed set and generates GitHub artifact attestations. Verify a downloaded asset with gh attestation verify <asset> -R Netroforge/bronom, then compare it with hashes.txt.

Dependabot checks npm packages and GitHub Actions weekly and groups related Electron, Vue/Vite, MCP, and TypeScript updates. GitHub Pages deploys independently from the desktop release workflow.