Give your software factory a browser

The eve software factory template turns GitHub and Linear work items into reviewed draft pull requests, working entirely from text: the issue body, a repository checkout, the diff, and your CI output. But many issues describe page behavior that the code alone won't show, like a checkout that fails on the third step, or a dashboard that renders incorrectly for one account type.

This guide adds KERNEL's eve extension to the factory's orchestrator, brokering user access via Vercel Connect. API keys stay out of your app, environment, and the model, and credentials are never handled by the agent.

You'll then put the browser to work on three workflows: reproducing a bug on request from an @mention, verifying a shipped fix on the preview deployment Vercel builds for every factory branch, and recording what the browser learned in the factory brain so every future run starts from it.

Deploy the template now, or read on if you have already done so.

Copy link to headingQuick start with an AI coding agent

If you're working with an AI coding agent like Claude Code or Cursor, use this prompt to have it make the changes for you:

Copy link to headingVercel Plugin

The Vercel Plugin turns your AI coding agent (e.g., OpenAI Codex, Claude Code, or Cursor) into a Vercel expert. It adds skills, slash commands, and current knowledge of the tools this guide uses, including eve and Vercel Connect. The plugin is optional; it isn't required to follow this guide.

npx plugins add vercel/vercel-plugin

Copy link to headingOverview

In this guide, you'll learn how to:

• Install KERNEL's eve extension and add it to the software factory.
• Broker browser access per user through Vercel Connect, so each teammate authorizes once, and no shared credentials exist anywhere.
• Add an approval gate and pin the extension’s tool allowlist.
• Sign Foreman (eve software factory) into a site via KERNEL-managed auth, with a saved profile so subsequent sessions start signed in.
• Reproduce a flow bug from an @mention and verify a fix on a preview deployment, watching either through a live-view URL.
• Record browser findings in the factory brain, where the unattended pipeline reads them on every run.

Copy link to headingPrerequisites

Before you begin, make sure you have:

• A Vercel account and a KERNEL account.
• The eve software factory deployed and cloned locally.

For local development, you also need Node.js 24+, pnpm, and the Vercel CLI.

Copy link to headingHow it works

KERNEL's eve extension packages one connection to its hosted MCP server. Once mounted, the tools surface under the kernel__browser__ namespace and eve discovers them at runtime, so Foreman ships no browser code of its own.

The extension also includes a browse skill that guides the model through a browsing task end-to-end.

The connection carries seven browser tools:

The extension attaches to the orchestrator, so the browser is available wherever a person is driving the software factory:

• @mentions on issues and pull requests
• Linear Agent Sessions
• The dev TUI

Each teammate authorizes KERNEL once via Vercel Connect, and the grant is cached thereafter. Every browser session runs with that person present, and they can watch or take over through its live URL.

Unattended runs have no person present, so they don't drive the browser. Labeled issues and the red-CI fix loop instead read browser findings from the factory brain, the shared memory every run loads at the start of a task. The split follows the template's trust model, where logged-in sessions run with a person present, and what they learn carries over to unattended runs as reviewed notes.

Copy link to headingSteps

Copy link to heading1. Add the extension from the registry

KERNEL has an entry in the eve registry, so one command installs @onkernel/eve-extension and creates the mount under agent/extensions/:

eve add extension/kernel

The extension defaults to KERNEL_API_KEY authentication. The next two steps swap that for Vercel Connect, so no key ever touches the project.

Copy link to heading2. Create and attach the connector

Link your directory to the Vercel project, then create the KERNEL connector:

vercel link
vercel connect create kernel --name kernel-mcp --connection-method mcp
vercel connect attach kernel/kernel-mcp

Confirm the UID with vercel connect list and leave KERNEL_API_KEY unset.

Copy link to heading3. Configure the mount with Vercel Connect

The mount itself is one line, pointed at the connector UID:

1
import kernel from "@onkernel/eve-extension";
2

3
export default kernel({ connect: "kernel/kernel-mcp" });

Copy link to heading4. Add an approval gate with a shadow connection

Adding an approval gate is recommended, and you can set it up by shadowing the extension's built-in browser connection.

Create a connection file with the same name, which takes precedence over the built-in version, then restate its defaults alongside the gate:

agent/extensions/kernel/
  extension.ts             # the mount from step 3
  connections/browser.ts   # shadows the extension's built-in "browser" connection

import { connect } from "@vercel/connect/eve";
import { defineMcpClientConnection } from "eve/connections";
import { once } from "eve/tools/approval";

export default defineMcpClientConnection({
  url: "https://mcp.onkernel.com/mcp",
  description: "KERNEL: cloud browsers, managed auth, profiles, and replays.",
  auth: connect("kernel/kernel-mcp"),
  approval: once(),
  tools: {
    allow: [
      "manage_browsers",
      "execute_playwright_code",
      "computer_action",
      "manage_auth_connections",
      "manage_profiles",
      "manage_proxies",
      "manage_replays",
    ],
  },
});

With this configuration:

• allow names the seven tools the extension enables by default. Any tool the server adds later stays undiscovered until you specify it here.
• browser_curl, manage_credentials, exec_command, and manage_browser_pools are disabled by default and stay out. Without manage_credentials, a sign-in only happens when a person completes it.
• once() pauses the first browser action of a session on an approval card, then lets the session run. To pause a specific tool on every call, such as execute_playwright_code, use the predicate pattern in agent/lib/github/approval.ts.

Copy link to heading5. Verify

Run the following commands to verify your setup:

pnpm validate
eve info

pnpm validate should finish with zero errors and zero warnings, and eve info should list the browser connection with exactly the seven allowed tools.

Then run pnpm dev and ask Foreman to open a page. The first browser action triggers a one-time Vercel Connect prompt to authorize KERNEL, then an approval card in the TUI. Approve both, and the session starts with a live URL you can watch.

Copy link to heading6. Sign in with KERNEL-managed auth

Foreman never types your password. When a task needs a sign-in, it uses manage_auth_connections to attach the domain to a browser profile, and KERNEL returns a hosted login page where you complete the sign-in yourself.

The hosted page supports Google, GitHub, and Microsoft SSO, and it handles TOTP, SMS, and email one-time codes.

Try it from the TUI:

log me into staging.example.com

After login succeeds, KERNEL saves the authenticated session to the profile specified in the connection. Any browser launched with that profile starts signed in to every domain the profile carries, so you sign in once, and all later sessions reuse it. Profile state is encrypted, and nothing typed on the hosted page reaches the API or the model. Sessions do expire eventually, and a fresh hosted link renews them.

Use the least-privileged account that still reproduces the bug, and prefer staging accounts. Everything the browser renders is untrusted input read from inside that account's session, so the less it can do, the less a steered session can reach.

Copy link to headingThree workflows to try

Copy link to headingReproduce a bug behind a login

@mention the bot on a GitHub issue that describes a flow:

@foreman using the staging profile, walk the checkout flow and find where it breaks

Foreman walks the flow in a real browser until it breaks, then reports the failing step. What it observes goes into the analyst's brief, so the plan and the acceptance criteria are built from a reproduced bug rather than a described one.

Copy link to headingVerify a fix on the preview deployment

Every branch the factory pushes gets a Vercel preview deployment before any PR opens. So, by the time a draft PR is opened, a running build of the fix already exists.

Ask Foreman to verify whether your fix works:

@foreman open the preview deployment for this branch and confirm the checkout flow completes at a 390px viewport

The factory already reviewed the branch against the diff and your repo's own checks. This pass confirms what those can't: that the fix works in a running application on the exact viewport you named before you mark the PR ready.

Copy link to headingTeach the factory what the browser saw

Some of what a browser session learns is durable: the staging environment runs Stripe in test mode, or the account picker only appears for multi-org users.

Ask Foreman to remember it:

@foreman record in the factory brain that checkout step three is a client-side redirect to /pay, so server logs won't show it

The factory brain is the shared memory every run reads at the start of a task, so a fact the browser established once now grounds every future run, including the unattended ones triggered by labeled issues and red CI. Browse once in an attended session, and the whole pipeline plans with what you found.

Copy link to headingHow the guardrails extend

The template treats work-item text as untrusted input, and a web page is more untrusted text, rendered inside a session that may be signed in to your accounts.

The browser follows the same rules:

• Page content is input, not instruction. The browse skill hands sign-ins, ambiguous choices, and sensitive actions back to the person driving the session, who can watch or take over through the live URL.
• Only the orchestrator drives the browser. Never add the extension under agent/subagents/. Stations run in task mode, which can't pause for a consent prompt, an approval card, or a sign-in hand-off, and the station that writes code should never hold web content in its context. The orchestrator browses and passes the stations a summary.
• People complete every sign-in. Vercel Connect authorization, the once() approval card, and the hosted login page all require one, and leaving manage_credentials out of the allowlist keeps it that way.

The template ships safety evals, and the browser needs one too. Add a case under evals/safety/ with a page that tries to instruct the agent, asserting Foreman reports an injection attempt rather than acting on it.

Copy link to headingTroubleshooting

Copy link to headingNext steps

• Build a software factory with eve: the template this guide builds on
• How to build a browser agent that works behind a login: the same KERNEL and Vercel Connect pairing in a user-facing agent
• KERNEL eve extension docs: the canonical reference for the mount, the full tool list, and connection overrides
• KERNEL managed auth docs: profiles, connections, and hosted login
• Vercel Connect: the access broker that mints per-user tokens