jawb
Join Discord

Roadmap and status

What's implemented today versus planned.

jawb is scaffolded from a product/technical/business blueprint whose full architecture spans a multi-year roadmap. This page tracks what's implemented today versus planned. Nothing under "Planned" is available yet.

Implemented today

  • Install: one-command installers for macOS, Linux and Windows that put jawb and its pinned jawbd on your machine, checked against published SHA-256 sums and, with minisign installed, signatures (Installation). The CLI starts the daemon when it isn't running.
  • Daemon and sessions: jawbd with token-authenticated, loopback-only HTTP; encrypted-at-rest profiles (default included); tabs and sessions that persist independently of the CLI process; incognito sessions; parallel tabs.
  • Read: observe (element list with stable, retargeting-aware IDs and revision diffs), read (Markdown/text/JSON page or element content), tools (WebMCP discovery: names and descriptions, no invocation), wait.
  • Act (via the compatibility bridge — a real, locally installed Chrome/Chromium driven headlessly): click, fill, type, select, check/uncheck, press, hover, scroll, upload, download, submit, media.
  • See (same bridge): viewport, emulate, screenshot.
  • Policy and confirmation: upload/download/submit/credential confirmation flows, and a stricter human-confirmation flow for classified purchase-like actions that --yes never satisfies. It is a safeguard for honest checkout flows, not a guarantee against a hostile page (Security and trust).
  • Security hardening: owner-only data directory, isolated-world bridge helpers, certificate errors fail navigation, and link-local and cloud-metadata addresses are always refused (Security and trust).
  • JavaScript-rendered pages: observe --js / read --js promote a tab to the bridge; a promoted tab stays there for its lifetime.
  • A Rust client SDK for the daemon's /v1 HTTP API, and a website SDK helper that declares WebMCP tools.

Full detail: the CLI reference.

In development

  • Desktop application. A desktop app that is a client of the same local daemon, not a second browser engine. It shows the daemon's status, the trace of every step, and a sidebar of the agent's open tabs with the steps run on each, and a tab's page as Markdown. An address bar opens or navigates a tab through the daemon, under the same policy as jawb open. An Approvals screen lists purchase-like actions the daemon is holding and lets you approve one (after typing purchase) or deny it. It uses the same credential file as jawb confirm, so it is a convenience, not a stronger check: a program running as you can still approve until an OS-mediated approval exists (Security and trust). It is not released yet; there is no installer to download.

Planned next

  • Routing. One router that picks the cheapest route that works for each action: a tool the site declares, the page's semantic structure, or the Chrome bridge. It must add no performance cost: the route is decided from what the daemon already holds, with no extra page read or browser call, and the timing benchmark checks for any slowdown. A tab can come back from the bridge once it no longer needs it.
  • Budgeted, perception-faithful observation. Ask for a size budget and get the most relevant elements first, with repeated structures (lists, tables, navigation) collapsed into groups the agent can expand, and a note of what was left out. The observation holds only what a person would see; hidden text is flagged and page content is labelled as untrusted.
  • Tools first. Invoking the WebMCP tools a site declares, behind the same policy checks as a click. The MCP server that lets agents call jawb directly over the same API is built and ships in the next release.
  • Workflow recording and replay. Every run recorded in a form that can be replayed, then deterministic replay of a recorded workflow without new model calls.
  • Guardrails. Content-integrity checks for hidden text and hidden instructions, a local-network rule (explicit localhost stays allowed; a public page reaching into your network is blocked), encrypted per-session downloads, an OS-mediated purchase approval, and one policy gate that every route goes through (Security and trust).
  • A timing benchmark. Time to first actionable observation, conventional Chromium automation vs. jawb, published as median and p95 once the harness runs reproducibly.

Later

  • Extensions and the WebAssembly plugin host behind them; see the planned first extensions
  • Licensing and team features: jawb is free for personal developers, and business and team use will need a paid licence. Everyone will sign in with a jawb account; sign-in never sends browsing content, and a signed-out or offline install keeps browsing during a grace period.
  • TypeScript and Python SDKs (placeholders only)
  • Native (non-bridge) execution of Act and See commands — they run on the Chromium bridge today; moving them to jawb's own engine crates is future work

See jawb-core's own README for the crate-by-crate implementation status.