Contents

MōBrowser 2.11.0

MōBrowser 2.11.0 adds built-in AI automation for development, a default Chrome DevTools debugging endpoint, and stronger security defaults for IPC and in-app navigation. This release also updates the runtime stack and includes improvements for macOS signing and native module project generation.

What’s new 

AI automation during development 

MōBrowser now includes a first-class way to drive a running app with AI agents during development. The new mobrowser agent CLI connects to an in-process automation server embedded in the app, so AI agents can inspect the UI, take screenshots, click elements, fill fields, run JavaScript, and collect console or network information without using Playwright or a separate browser.

The agent sees the app through a compact accessibility snapshot where interactive elements get stable references, making actions easier to target and more reliable than coordinate-based automation. It can run in the normal interactive mode so you can watch what happens, or in autonomous invisible mode for background tasks.

This is especially useful for end-to-end checks, AI-assisted debugging, and iterative UI work. It’s enabled by default in development mode. You can ask your AI agent to launch the app, take a screenshot, click a button, fill a form, run a JavaScript snippet, and more.

Remote debugging port in development mode 

MōBrowser apps now expose a Chrome DevTools Protocol endpoint by default in development mode. When running the app in development mode with npm run dev, the app is available for debugging and automation at http:// localhost:9222, making it easier to use tools such as Playwright for E2E testing and AI-assisted app interaction.

IPC security gates 

Renderer-to-main IPC is now protected by trusted origins by default. MōBrowser exposes the generated RPC bridge only to the application origin and origins explicitly listed in app.trustedOrigins, so remote pages and iframes loaded from untrusted origins no longer receive window.__MOBROWSER__.rpc.

If your app intentionally loads remote content that should use IPC, add that origin to trustedOrigins in mobrowser.conf.json:

"trustedOrigins": [ "https://app.example.com", "https://*.example.com" ]

The main process also validates the frame origin before dispatching RPC requests or stream subscriptions. This gives IPC a second enforcement point even if untrusted remote content attempts to bypass the renderer-side bridge exposure.

Blocking navigation to external URLs 

MōBrowser now restricts top-level in-app navigation to trusted destinations by default. Primary main-frame navigations are allowed only to the application origin from app.url, origins listed in app.trustedOrigins, app-served custom schemes registered with protocol.handle(), and about:blank.

Untrusted top-level navigation attempts are canceled before the destination document loads. This applies to direct loads, renderer-initiated changes such as window.location, and redirects to untrusted origins.

If your app intentionally navigates to remote content, add the destination origin to trustedOrigins in mobrowser.conf.json:

"trustedOrigins": [ "https://example.com" ]

You can override the default behavior and allow navigation to any origin by handling the navigation event in the main process:

import { BrowserWindow, NavigationParams } from '@mobrowser/api';

const win = new BrowserWindow()
win.browser.handle('navigation', (params: NavigationParams) => {
  if (params.isTrusted || params.origin === 'https://example.com') {
    return 'proceed'
  }
  return 'cancel'
})

Stack updates 

  • Updated Node.js to version 24.17.0.
  • Updated Chromium to version 150.0.7871.47.

Fixes and improvements 

  • Fixed macOS bundle signing failures caused by over-aggressive log redaction. The signing check now keeps the certificate kind, such as Developer ID Application, visible for validation while still redacting the team-specific certificate identity from logs.
  • Improved the generated CMakeLists.txt for apps with native modules by adding platform-specific placeholders for dependencies, include directories, compile definitions, and linked libraries. These hints make it clearer where to put Windows, macOS, and Linux-specific native configuration and help avoid cross-platform build errors caused by incompatible dependencies.