nephew

Your logged-in identity, in any agent sandbox.

PORTABLE · CONTINUOUS · YOURS

Nephew is the profile layer for the sandbox providers you already use. It carries one logged-in browser identity — cookies, session state, a coherent fingerprint, and a pinned egress IP — into Modal, Steel, Browser Use, and Browserbase. It is not another sandbox, and it does not replace them: your jobs still run on your provider, under your account. Nephew is the identity they run as.

Start here

curl -fsSL https://nephew.ai/install | sh

nephew init                 # connect your own provider accounts
nephew capture              # sign in once, in your own browser
nephew run <job> --provider modal|steel|browseruse|browserbase
nephew run <job> --provider steel --handoff   # if challenged, take over live
nephew receipt verify <file>                 # verify a signed run receipt

Every run opens with a three-line trust receipt — the profile, the fingerprint it must match, and the egress it must come from:

profile     modal-proxy-20261030 · owner-held bundle · loaded from your vault
fingerprint 2ef43e20ca · seed 1000 · windows/Chrome
egress      brightdata-zone-isp_proxy3 · pinned

What you bring

• Your own provider accounts and keys — a Modal token pair, a Steel API key, a Browser Use API key, a Browserbase API key. Nephew runs on your accounts; your provider billing stays yours.
• Your own Bright Data zone — the dedicated IP your identity egresses from, pinned in the profile recipe.
• Node.js 22 or newer on the machine you run the CLI from.

There is no Nephew account to create and no Nephew cloud in the middle.

The keys the CLI reads from your environment:

PROFILE_ENCRYPTION_KEY  bundle decryption key (capture + live runs)
MODAL_TOKEN_ID / MODAL_TOKEN_SECRET  Modal connection (provider: modal)
STEEL_API_KEY / BROWSER_USE_API_KEY / BRIGHTDATA_API_KEY  provider keys (nephew init checks them)

How it works

1. Capture once. Sign in once; the session is sealed into an encrypted bundle you hold — profile state, fingerprint recipe, pinned proxy reference. Keys never leave your machine.

   nephew capture [--name <id>] [--human <who>] [--bundle <dir>] [--sites <url,url>] [--seed <n>]

2. Run anywhere. nephew run starts your provider sandbox, measures the live browser, and checks it against the recipe. The fingerprint gate must accept before any state is released — on mismatch, the run refuses.

   nephew run <job> --provider steel|browseruse|modal|browserbase [--dry-run] [--bundle <dir>] [--handoff [--handoff-ttl <seconds>] [--handoff-port <n>]]

3. Challenged? Hand off, live. If a site challenges the run, it pauses with LOGIN_REQUIRED. On Steel, Browser Use, and Browserbase the run can hold its live session instead of closing it: the profile's designated human opens a local page, watches the session stream live, and fixes the login in place with their own mouse and keyboard. One controller, a per-handoff token, and a hard deadline (6 minutes by default) that late arrival cannot extend. Hand control back and the fixed session is captured into the same bundle; end the run and nothing is captured. Modal cannot attach a live handoff yet — its browser runs inside the sandbox with no host-side session to lend — so a Modal run that needs a login returns the plain pause.
4. Capture back. When the job ends, the live session is sealed back into the same bundle. One identity, no forks — the next run, on any provider, continues where the last one stopped.

Signed run receipts

A run leaves a signed record: profile, run, provider, the fingerprint hashes it measured, the egress it observed, start and end times, the outcome, how many minutes of human attention it took, and whether a handoff was used. The receipt is signed with your own Ed25519 key — the same key that signs nephew revoke's deletion receipt — and stored in ~/.nephew/receipts/. Anyone you hand it to can verify it against your public key:

nephew receipt verify <file>   # PASS, or FAIL naming the field that changed

That is the compliance shape of the product: a run's record that a third party can check without trusting us, because there is no Nephew server in the middle to trust.

Trust facts, for the curl | sh skeptic

• The installer writes exactly two things: the app to ~/.local/lib/nephew and a launcher to ~/.local/bin/nephew. No sudo, nothing else.
• The download is verified against the published SHA256SUMS before anything is installed; a mismatch aborts the install.
• Your keys live on your machine only — environment variables and your own provider configs. No Nephew server exists, and no server ever holds your profile.
• nephew revoke destroys a bundle and its key material, and leaves an Ed25519-signed deletion receipt you can verify independently.
• A handoff writes an event record of counts and identifiers only — frames relayed, inputs forwarded, outcome. No frames, no keystrokes, no page content, no token.

nephew revoke [--bundle <dir>] [--key-file <file>] [--receipt <file>]

Compatibility

Today: Modal, Steel, Browser Use, Browserbase — the same bundle, the same gate, all four. On Browserbase the bundle is the only state a session sees: Nephew never uses Browserbase Contexts (their provider-native persistent profiles), and sessions are created with your API key alone — no project id, no stored profile on their side.

Measured proof

• Same profile, this machine vs a Modal sandbox: identical fingerprints — all 10 measured elements, canvas included — with the pinned font pack in both environments.
• Pinned egress, verified live: a Modal run egressed from the profile's own dedicated IP, exactly as pinned in its recipe. The gate checked the egress before releasing state and accepted, and the session was restored. The address itself is carried in the run's own metrics record — your runs produce the same record for your IPs.
• Baseline restores: ~6.4 s on Steel, ~7.8 s on Browser Use, ~5.7 s on Browserbase; full Modal runs 10–27 s in-session.
• 0 login prompts, 0 MFA prompts across the Steel, Browser Use, Modal, and Browserbase proof runs.

Plain limits

• A site can still challenge a run. When it does, the run pauses with LOGIN_REQUIRED; the live handoff above is the recovery on Steel, Browser Use, and Browserbase, and on Modal the recovery is still re-capture and retry.
• Browserbase sessions: the 5-minute timeout shown in a project's settings is the default when no timeout is requested. Nephew requests an explicit session window (1 hour) — measured granted in full, including a probe at the 21,600-second API maximum.
• One dedicated IP per identity, per-profile by design.
• A handoff is one designated human, one controller, on a loopback page — and it ends at its deadline whether the login is fixed or not.
• No "works on every site" claims. Above are the runs we actually measured; yours are measured the same way, and every run writes its own metrics record.

Surfaces

The nephew CLI (init · capture · run · revoke · receipt verify), an MCP server (nephew mcp) exposing the profile_run tool with the same gate, a structured LOGIN_REQUIRED pause result, and — on Steel, Browser Use, and Browserbase — the live handoff handle routed with it, and a TypeScript helper (withProfile) that wraps a job function in a carried identity — Steel, Browser Use, and Browserbase today; Modal runs through the CLI. A Python decorator (with_profile, in the nephew Python package) wraps a Python job the same way, over the same gate and the same signed run receipts.

Start the MCP server (stdio):

nephew mcp

A profile_run call:

{ "tool": "profile_run",
  "args": { "job": "nightly-recon", "provider": "steel", "bundle": "/path/to/bundle" } }

The TypeScript helper:

import { withProfile } from "./src/with-profile.ts";
await withProfile(bundleDir, "steel", async ({ cdp, sessionId }) => {
  // already logged in as the owner — no login code in this file
});

The Python decorator:

from nephew import with_profile
from playwright.sync_api import sync_playwright

with with_profile(bundle="/path/to/bundle", provider="steel") as session:
    with sync_playwright() as pw:
        browser = pw.chromium.connect_over_cdp(session.cdp_url)
        # already logged in as the owner — no login code here

Reading this as an agent? The machine-readable twin of this page is /llms.txt, and the structured manifest is /nephew.json.

Plans

Your login, your device identity, your IP — in any agent run.

You pay for profiles — identities you own and can revoke or take elsewhere — and for run-hours, the time an agent spends logged in as you. No per-seat fees. We never store your keys.