navette — the browser for agents

navette — v1.9.0

エージェントのためのブラウザーです。 OS に標準搭載されている WebView を動かす、小さな Rust バイナリです。Chromium もダウンロードも不要で、RAM を大量に消費しません。

Navette はフランス語でシャトルを意味します。エージェントをページからページへ運ぶ小さな乗り物です。いつでも燃料切れの心配がなく（エンジンは OS に標準搭載されています）、気にならないほど軽量で、人間向けウェブのごみを飛ばすため、エージェントが処理する必要もありません。

Rust の単一バイナリで、3 つのモードに対応します：

$ ls -lh target/release/navette
-rwxr-xr-x  1 user  staff   725K  navette

macOS でのインストールサイズは 725 KB です（リリースバイナリで確認できます。ログイン状態を保存する OS キーチェーンのストアには、約 100 KB 必要です）。Windows-x64／linux-x64 では wry バックエンドを使用します。Playwright は 218 MB、Lightpanda は 96 MB です（スクリーンショットには対応していません）。測定値は、1 つのコマンドで再現できます（BENCHMARKS.md）。

• 測定したすべての指標で Playwright + Chromium より高速です — インストール、コールドスタート、ナビゲーションから読み取りまで（8 ms）、操作（1 ms）、ピーク RAM 使用量、100 ページのクロール（0.9～2.8 秒。Lightpanda と誤差の範囲内で同等、Playwright より約 2～3 倍高速）、実ウェブでの成功率（95～100% 対 85%）。
• レンダリングしながら、Lightpanda と同等の速度でクロールします（バイアスゼロの raw-CDP プローブでは、誤差の範囲内で同等です。この条件で Lightpanda は最速のページリーダーで、3.3～3.4 ms です。部分的な DOM を解析しますが、レンダリングはできません。一方、navette はフルレンダリング対応のリーダーとして最速で、同一のクライアントを使った場合、17.9～19.4 ms です。Chromium は 28～34 ms です）。
• **Lightpanda が優れている 2 つの指標（新規プロセスの起動とピーク RAM 使用量）は、レンダリングの代償です。**エージェントが静的ページを読むだけなら、fetch + readability を使ってください。JavaScript、セッション、操作、ビジョンが必要なら、その代償こそがこの製品です。

FAQ

Apple の Safari MCP サーバー（2026）ではだめなのですか？ 同じ考え方ですが、対象範囲が異なります。navette はエージェントを第一に設計されており（8 つのプリミティブ、ゴーストウィンドウ、常駐デーモン）、オープンソースで、設計上クロスプラットフォームです（Windows の WebView2 は Chromium であり、プリインストールされています）。Apple のものは macOS と Safari に特化しています。

fetch + readability だけではだめなのですか？ 静的なページなら、それで十分です。どれよりも優れています。navette は fetch では対応できないもの、つまり JS で構築されたページ、ログイン、セッション、フォーム、スクリーンショット、人間のような操作に対応するためのものです。

ML 抽出モデルではだめなのですか？ これは順位付けではなく、2 つの異なる選択肢です。この領域で ML 側を担うのが pulpie-mcp です。学習済みの抽出モデルは、エージェンシーのテンプレートや崩れた CMS の出力など、敵対的な HTML にも対応できます。DOM をたどる方式では誤ったノードを選ぶようなケースでも、ページあたりおよそ ~600 ms の計算時間で処理できます。navette のネイティブ DOM 走査はページあたり ~10 msで、マークアップが正常な場合に優れています。ドキュメント、ニュース、開発ツールのページの大半、つまりエージェントが実際に読むものの多くがこれに当たります。両方のレイヤーは組み合わせられます。あるページのマークアップが敵対的で、ネイティブ抽出では無関係な結果が返る場合は、そのページの生の HTML を ML 処理に渡してください。

navette はクローラーですか？ いいえ。意図的にそうしていません。navette は渡された URL に対して移動、読み取り、スクリーンショット撮影、操作を行います。robots → sitemap → リンク検出は上位のレイヤーであり、中核となるプリミティブではありません。対象に実際のブラウザーエンジンが必要な場合は、クローラーから navette を利用してください。

スクリーンショットの忠実度はどうですか？ キャプチャは各エンジンのネイティブ方式（v1.3+）で行います。再レンダリングではなく、コンポジターが描画した内容をビューポートサイズで取得します。キャプチャを再現可能にするには、移動前にビューポートを設定してください。ページ全体のキャプチャはまだ実装されていません。近似で済ませず、その状況を正直に記録しています。

セキュリティはどうですか？ サーバーは 127.0.0.1 のみでバインドされ、ローカル以外からの Host ヘッダーは拒否されます（DNS リバインディング対策。/health は対象外です）。トークン比較は定時間で行われ、ログではプロキシ URL の認証情報が伏せられます。セッションの分離はすべてのエンジンで CI により強制されています。あるセッションにインポートされた Cookie が別のセッションの Cookie jar に現れた場合、ビルドは失敗します。macOS（セッションごとに非永続的な WKWebsiteDataStore） · Windows（セッションごとに 1 つの WebView2 プロファイル + InPrivate — InPrivate だけでは、コントローラー間で 1 つのプロファイルが共有されます。#6） · Linux（セッションごとに新しい WebContext を作成。Cookie はディスクに保存されません — HTTP キャッシュと HSTS は保存されます。#6）。実行間で状態を移す場合は、明示的に state_export / state_import を使用します。エージェントの JS はターミナルではなく、OS の WebKit サンドボックス内で実行されます。プライベートなノート PC 以外で使う場合は、--token SECRET を指定すると、/health 以外のすべてのルートで Authorization: Bearer が必須になります。MCP ホストは NAVETTE_TOKEN 環境変数を設定して接続します。ログイン状態は平文のサイドカーファイルではなく、OS のキーチェーンに保存してください（#8）。navette state save NAME はデーモン内に Cookie jar を保存し、返されるのはメタデータだけです。リクエストには名前を含め、秘密情報はキーチェーンに保存します。新しいバイナリでは macOS が再度確認を求めます（ACL）。これは各リリースに対する暗黙の同意として機能します。認証情報の扱いはさらに一段階進んでいます（ステージ 2、リリース済み）。人間が navette creds set SITE でログイン情報を保存すると（stdin から非表示で入力し、セッションの現在のページの正確なオリジンに紐付けます）、任意のエージェントが POST /login {"site": SITE} でログインフォームに入力できます。パスワードはデーモン内で解決されてページに挿入され、リクエスト、レスポンス、ログには一切現れません。また、読み出し API は存在しません。別のオリジンでは入力が拒否されるため、悪意あるページやプロンプトインジェクションを受けたエージェントが秘密情報を収集したり、別の場所へ送ったりすることはできません。2FA は人間が対応します（session_show）。正直に言うと、入力時にはパスワードがページに届きます。これは人間が手入力する場合と同じで、オリジンへの紐付けが防御策です。

オペレーター用フラグ（serve）：--proxy URL（HTTP CONNECT / SOCKS5、wry バックエンド。macOS ではシステムプロキシに従います）、--user-agent UA（serve ごとのオーバーライド）、--idle-release MIN（アイドル状態の WebKit セッションを解放し、デーモンは常駐します）。

ビルドと実行

brew install slabbdev/tap/navette   # macOS arm64
cargo install navette-browser   # any platform, from source
docker run -i --rm ghcr.io/slabbdev/navette navette mcp   # container, stdio MCP (amd64+arm64)
navette serve --port 8765       # HTTP API on loopback
navette mcp                     # MCP stdio for agent hosts
navette state save NAME         # the session's login state → OS keychain
navette creds set NAME          # a login the agent can use but never see
navette install-daemon          # resident: warm from login

または、ソースからビルドします。

cargo build --release          # rustup; macOS fully shipped — Windows (WebView2) / Linux (WebKitGTK) backends aboard
./target/release/navette serve --port 8765   # HTTP API on loopback
./target/release/navette mcp                 # MCP stdio for agent hosts
./target/release/navette install-daemon      # resident: warm from login, 24 ms first page
./target/release/navette uninstall-daemon

mcp モードでは、リッスンしているプロセスがなければ serve が自動的に起動します（すでに別の navette がそのポートを提供している場合は、競合せず待機します）。常駐デーモンは KeepAlive を設定した LaunchAgent です。セッションがウォーム状態であれば、エージェントが感じるコールドスタートは 24～37 ms に短縮されます。--idle-release MIN を指定すると、この時間帯に実用的な余裕が生まれます。アイドル状態のセッションは解放され、その後の最初のリクエストは事前ウォーム経路を通じて再びウォーム状態になり、約 100 ms で応答します。デーモン自体が終了することはありません。

HTTP API（127.0.0.1 のみ、JSON）

ルート	本文	戻り値
GET /health	—	{ok, name, engine}
GET /sessions	—	URL とタイトルを含むセッション
POST /navigate	{url, session?, with_content?, format?}	{ok, url, title[, content]} — with_content を指定すると、読み取りを 1 回のラウンドトリップにまとめます
POST /read	{session?, format?} markdown/text/html	{ok, content}
POST /screenshot	{session?}	PNG バイト列
POST /click	{selector, session?, wait_navigation?}	{ok}（実際のポインターおよびマウスイベントを発生させます。Radix／HeadlessUI のメニューも開けます。フォーム POST によるナビゲーションの自動待機はオプトインです）
POST /type	{selector, value, session?}	{ok}（React 対応のネイティブセッター）
POST /evaluate	{js, session?}	{ok, result}
POST /wait	{selector, ms?, session?}	{ok}
POST /sessions/state	{session, store?}	Cookie の JSON（ログイン済み状態）。store を指定すると、Cookie ジャーはその名前で OS のキーチェーンに保存され、{stored, origin, cookies} のみが返されます。Cookie ジャーがネットワーク経由で送信されることはありません
POST /sessions/load	{session, cookies} または {session, store}	{ok, imported[, origin, saved_at]} JSON またはキーチェーンからログイン済み状態を復元します
GET /states	—	保存された状態（名前、オリジン、タイムスタンプ）。Cookie ジャーは含まれません
POST /states/delete	{name}	{ok} 1 件を削除します
POST /creds/set	{site, username, password, session}	{site, origin} — 人間による操作が必要です（CLI は非表示の stdin から入力を求めます）。認証情報はセッションのページと完全一致するオリジンに紐付けられます
GET /creds	—	サイト、オリジン、ユーザー名。パスワードは含まれません
POST /creds/delete	{site}	{ok} 1 件を削除します
POST /login	{site, session?, submit?}	キーチェーンの情報でログインフォームに入力し、送信します。パスワードがリクエスト、レスポンス、ログに現れることはありません。セッションが認証情報のオリジンにない場合は 403 を返します
POST /sessions/viewport	{width, height, session?}	{ok, width, height} ビューポートを設定します（デフォルトは 1280x800）
POST /sessions/show	{session?}	{ok, visible} セッションのウィンドウを画面上に表示します。タイトル付きで、キー入力が可能な状態にし、中央に配置します。セッション内で一度だけ人間がログインする場合に使用します
POST /sessions/hide	{session?}	{ok, visible} ウィンドウを再び画面外に移動します（セッションと状態はそのままです）
POST /hover	{selector, session?}	{ok}（要素の中央で mouseover／mousemove を発生させます）
POST /key	{key, selector?, session?}	{ok}（フォーカスされた要素で keydown と keyup を発生させます）
POST /scroll	{y?, selector?, session?}	{ok, y} 絶対スクロールまたは scrollIntoView
POST /upload	{selector, filename, content_base64, mime?, session?}	{ok, files} — メモリー内のコンテンツを使ってファイル入力欄にファイルを設定します（DataTransfer を使用し、OS のダイアログは表示しません）
POST /sessions/close	{session}	{ok}

セッションは必要に応じて作成されます。ゴーストウィンドウは、スクリーンショットが必要な場合にのみアタッチされます。

JS ダイアログ（alert／confirm／prompt）はページ内で自動的に処理されます。alert はログに記録して何もせず、confirm は承認し、prompt はデフォルト値を返します。エージェントが非表示のモーダルでデッドロックすることはありません。

エージェントホスト向け MCP

一度登録するだけです（ZCode の例、ワークスペースの .zcode/config.json）：

{ "mcp": { "servers": { "navette": {
    "command": "/abs/path/to/navette/target/release/navette",
    "args": ["mcp"]
} } } }

ホストは 19 個のツールを利用できます：navigate、read、screenshot（MCP の画像コンテンツとして返され、エージェントはページを見ます）、click、hover、type、key、evaluate、wait、scroll、upload、viewport、sessions、session_close、session_show / session_hide（ウィンドウを画面上に表示して人間がログインできるようにし、その後、ウィンドウを画面外に戻します。状態は保持されます）、login（キーチェーンから入力して送信します。エージェントにパスワードが見えることはありません）、state_export / state_import（Cookie。Playwright の storageState 相当です。任意の store 名を指定すると、Cookie 情報を OS のキーチェーンに保存できるため、ネットワーク上を送信されることはありません）。

アーキテクチャ

src/main.rs          HTTP server (std::net), routes, agent-first JS snippets
src/mcp.rs           MCP stdio adapter + serve auto-start
src/webviewkit.rs    the kit contract — a trait every backend must implement,
                     so surface parity is compile-enforced (a backend that
                     misses a primitive or drifts on a signature won't build)
src/backend_macos.rs WKWebView via raw objc2 — ghost windows, lazy attach,
                     measured cold-start ordering (AppKit -> listener -> pre-warm)
src/backend_wry.rs   Windows (WebView2) / Linux (WebKitGTK) via wry + tao —
                     same surface, IPC-shim results, URL-matched navigation
src/backend_stub.rs  fallback for other targets (placeholder, same contract)

8 個のプリミティブはエンジンに依存しません。各プラットフォームのバックエンドは、このインターフェイスの背後にあるシステム WebView 上の薄いレイヤーです。このインターフェイスは現在、WebviewKit トレイトによって固定されており、将来、独自に実装するバックエンド（wry を使わない、WebKitGTK/WebView2 の直接 FFI）が接続する境界となります。エンジン戦略はシステム優先、埋め込み型をフォールバックとします（WebView2 Fixed Version / apt 経由の WebKitGTK / WPE）。詳しくは ONEPAGER.md をご覧ください。

ステータス

v1.9.0 (2026-10-08) — 現行バージョンです。macOS でネイティブキー入力を検証済み：show_window がフォーカスゲートになります（ゴーストのウィンドウはタイトル付きのキーウィンドウになり、Window Server が isKeyWindow を確認してから CGEvent が送信されます。そのため、キー入力が別のアプリに届くことはありません）。単一文字は Unicode 文字列を添えて送信されるため、どのキーボードレイアウトでも、エージェントが指定した文字が e.key に届きます（AZERTY で検証済み：a、Enter、Z、Tab、ArrowLeft はすべてネイティブモードで isTrusted: true として届きました）。mode: native を報告する前に、ページ内で入力の配信を検証します。検証が不十分な場合は、正直に合成入力へフォールバックします。また、遅い環境や競合のある環境に対応する NAVETTE_EVAL_TIMEOUT_SECS（デフォルト 20、5～300 に制限。#7 の緩和策）を追加しました。3 つのエンジンすべてで、ネイティブ入力を優先して試す方式を採用しました：SendInput（Windows、エンドツーエンドで検証済み）、XTEST（Linux/X11）、CGEvents（macOS、検証済み）。

v1.8.1 (2026-10-08) — セッション分離を、すべてのエンジンで CI により強制します。セッション分離を、すべてのエンジンで CI により強制：各セッションには、Windows では専用の WebView2 プロファイルと InPrivate（InPrivate だけではコントローラー間で 1 つのプロファイルを共有することを実測で確認済み。名前付きプロファイルによってセッションごとに Cookie／ストレージ／キャッシュが分離されます）、macOS では非永続的な WKWebsiteDataStore、Linux では分離された WebContext が割り当てられます。セッション間で Cookie が漏洩すると、3 つすべての OS でビルドが失敗するようになりました。セキュリティ強化：一定時間のトークン比較、DNS リバインディングに対する Host ガード（ローカル以外の Host は 403、/health は対象外）、ログ内のプロキシ認証情報の秘匿。また、demo/signed-webhook では、改ざん防止された相手方イベントと、差分による不正分析を実装しました（HMAC チェーン付きのモック、#5 を解決）。料金所データセットは x402／ペイウォールのシグナルとともに CC BY 4.0 で公開されました（v1.8.0）。

v1.8.0 (2026-10-08) — セッションウィンドウの表示と実際のポインターイベントに対応しました：session_show/session_hide を使うと、ゴーストセッションをページ状態を保ったまま画面上に表示して、一度限りの人間によるログイン（OAuth、2FA、CAPTCHA）に使い、その後、再び画面外に戻せます。/click はマウスイベントの前に pointerover/pointerdown/pointerup を送信するため、Radix／headless-UI コンポーネントが人間の操作と同じように開きます。macOS の /wait におけるブール値の文字列化バグも修正しました（ブリッジは 1 を返す一方、プローブは true を期待しており、存在するセレクターがすべて「タイムアウト」していました）。内部実装では、バックエンドの契約を webviewkit キットに統一し、バックエンドごとのコンパイル時検証を行います。料金所の第 2 ラウンド：ウォールドウェブのベンチマークで、robots.txt の AI 条項と llms.txt に加え、x402／ペイウォールのシグナルも測定します（5 カテゴリー、200 URL。データセットは bench/ にあり、CC BY 4.0 で公開）。API のないサイトで公開するための、動作する一通りのレシピを demo/dailydev として提供します。 v1.7.0 (2026-10-07) — ネイティブキーボード入力：POST /key はまず実際の OS レベルイベント（macOS では CGEvent、Windows では SendInput、Linux では XTEST — isTrusted: true）を試し、自動的に合成イベントのディスパッチにフォールバックして、実行された mode を報告します。ネイティブ入力がエンドツーエンドで検証済みのプラットフォームは Windows です。macOS とヘッドレス Linux では問題なくフォールバックします（各プラットフォームの現状については、issue #3 をご覧ください）。オペレーター向けリリース：--token（HTTP API の Bearer 認証）、--proxy（serve ごとの HTTP CONNECT／SOCKS5）、--user-agent（serve ごとの上書き）。アイドル解放ウォッチドッグ：navette serve --idle-release 15 は、15 分間リクエストがないと WebKit セッションを解放します。デーモンは常駐したまま、メモリが解放され、次のリクエストに応じて再び準備されます（macOS と Linux で検証済み）。ファイルアップロード（ページ側の DataTransfer — OS のダイアログは不要）やスクロールを含む 18 個の MCP ツールを提供。crates.io で navette-browser として公開されています（cargo install navette-browser → navette）。bench ワークフローでは、3 つすべてのエンジンでナビゲーション／読み取り／スクリーンショットを計測します。3 つすべての OS で CI が成功：macOS（WKWebView）、Windows（WebView2）、Linux（WebKitGTK）。

最近のリリース：v1.8.1 — エンジンをまたぐセッション分離（CI で検証）、定時間トークン、DNS リバインディング対策、docs/SECURITY.md · v1.8.0 — 表示可能なセッションウィンドウ、ポインターイベントによるクリック、macOS の /wait 修正、webviewkit キット、tollbooth 第 2 弾 · v1.7.0 — ネイティブキーボード入力（まず /key を試行し、mode を正確に報告） · v1.6.0 — オペレーター向けリリース（--token、--proxy、--user-agent）、linux-arm64 アセット · v1.5.0 — アイドル解放ウォッチドッグ、tollbooth ベンチハーネス、ネイティブ抽出と ML 抽出のトレードオフを文書化 · v1.4.1 — コンテナイメージ（ghcr、amd64+arm64）、--help／--version、brew tap、公式 MCP レジストリへの掲載 · v1.3.0 — 全プラットフォームで機能を統一（各エンジンのネイティブスクリーンショット、Cookie 状態のエクスポート／インポート、ビューポート制御、全環境での常駐デーモン、ホバーとキー入力、自動処理されるダイアログ）。

既知の未対応機能を明記します：実際の（OS レベルの）マウス入力、リクエスト／レスポンスのネットワークインターセプト、OS のファイルダイアログ操作。MIT ライセンス。