Jet Browser

Jet Browser is a replaceable browser-runtime boundary for an agent or a deterministic test runner. It runs one isolated WPE WebKit session per container and exposes ordered JSONL commands for navigation, native input, semantic inspection, screenshots and cleanup. This skill guides you through setting it up safely, verifying it, and integrating its documented contract.

The scope is intentionally narrow. Model selection, reasoning, credentials and orchestration stay in the calling project. Jet Browser is a browser runtime, not an agent framework, hosted proxy network, anti-bot service, or bridge to a personal Chrome profile.

Use it when a project needs a self-hosted browser process with an explicit container lifecycle, when a harness wants framework-neutral ordered JSONL instead of a bundled agent loop, when native pointer, keyboard, touch, DOM and screenshot evidence should share one runtime, or when a repository needs a reproducible offline smoke test or a GitHub Actions browser-runtime check.

Do not use it to control an already-running personal Chrome or to reuse its logged-in state; use a permission-approved CDP workflow for that. Jet Browser uses WPE WebKit, not Chromium, so Chrome-only extension, enterprise-policy and CDP contracts do not apply. Do not promise stealth, CAPTCHA solving or public-site success. The documented flow needs Docker and Node.js 24+, source development also needs the Rust toolchain, and the published v0.6.7 image targets linux/amd64, so ARM hosts need emulation or a source build.

The skill begins by confirming that you want a separate container rather than your daily browser, then checks for Docker and Node.js 24+ and reports anything missing instead of claiming verification. It asks you to identify an immutable release or full commit, inspect the repository's package.json, lifecycle scripts, lockfile, Dockerfiles and executables, and obtain explicit approval before downloading and again before installing dependencies, building images or starting containers. The reviewed commit for v0.6.7 is 882b17ab1b865560f17dbfeeeea0a7b40b95a146.

The key output is the observed JSON result of the standalone acceptance flow. A passing run must start the local page, verify the JavaScript marker, type through the native input path, capture a PNG, keep the smoke browser's outbound network disabled, and shut the container down cleanly. For source changes, npm test and cargo test --all-targets are also run. The skill never reports a pass when any step did not actually complete. The core commands are:

npm ci
npm run standalone

For integration, read docs/demo.md for the container lifecycle and docs/agent-tools.md for tool declarations, and prefer the versioned declarations exported by sdk/tools.mjs rather than inventing tool names, fields or response shapes. Send one JSON command per line, consume one JSON response per line, preserve ordering, bound inputs and outputs in your harness, and close the session in guaranteed cleanup. A GitHub Actions workflow can verify the public linux/amd64 release image by pinning the Action to the reviewed full commit.

Keep one container per mutually untrusted session, mount profile or download paths explicitly, and never pass unrelated host credentials in. Evaluation, imported profiles, downloads and outbound network access are privileged capabilities, so the calling application must define its own authorization and policy gates. Use semantic evidence for target selection and screenshots for visual verification.

Engineers building agent harnesses, test infrastructure or CI checks who want a self-hosted, container-isolated browser with a clean JSONL contract, and who value careful supply-chain habits such as pinned commits, lockfile installs and explicit approvals. The published ready-time and memory figures come from a pinned offline fixture and should not be read as a measure of public-site success or long-running stability.