Member browsers

What it is

The Browser an AI Employee normally uses is a headless Chromium inside the Genosyn container. It is fine for public pages and for logins you are willing to store in Genosyn, but it is not your computer: it has a different IP, a different device fingerprint, and none of the sessions you are already signed into.

A member browser moves the browsing to your machine. Genosyn can never dial your laptop, so the laptop dials Genosyn: the bridge holds one outbound WebSocket, and Chrome DevTools traffic rides over it. Inside the App, Genosyn points Playwright at a single-use endpoint bound to 127.0.0.1 that forwards down that socket. Nothing about the tools changes — the same sixteen browser_* tools, the same ref-annotated snapshots, the same live view and take-over.

Each browser belongs to one Member. It is not a company-wide resource: it appears only in your own settings, only you can point a conversation at it, and only you can watch it.

Why it is a dedicated profile

This is the part worth reading before you connect anything, because a reader who assumes "my browser" means "my open browser" will feel misled the first time they look at the window.

• Chrome refuses. Since Chrome 136, --remote-debugging-port is ignored when the profile is the default one. On branded Google Chrome that check is compiled in, there is no flag that turns it off, and the pipe-based alternative is gated the same way. Automating your everyday profile is not something Genosyn declined to build; it is something the browser does not permit.
• It should refuse. Attaching an automation driver to a browser full of your own tabs would let the model read them, would put your request headers in front of a server, and would have a robot answering your JavaScript dialogs. A separate profile makes the blast radius the Genosyn window and nothing else.

So the practical shape is: a real Google Chrome, on your machine, with your network and your screen, in a window that belongs to Genosyn. The first time you connect it, that window is signed into nothing at all. You sign in there once per site — the profile persists on your disk between runs, so you do not repeat it. Passwords you type into that window are yours; Genosyn never copies its cookie jar, and never writes its storage state into the App's data directory the way it does for its own Chromium.

Connecting one

Go to Settings → Browsers and click Connect a browser. Give it a name you will recognise in a picker ("Chrome on my MacBook") and fill in the list of sites it may open. Genosyn shows a pairing code once — it is stored only as a hash, works exactly once, and expires after ten minutes. If you lose it, ask for a new one; that also invalidates whatever the old one produced.

On the computer itself you need Node 22 or newer (node -v) and Google Chrome installed. Download the bridge and pair it:

curl -fsSL https://your-genosyn.example.com/api/internal/member-browsers/agent.mjs \
  -o genosyn-bridge.mjs
node genosyn-bridge.mjs pair --server https://your-genosyn.example.com --code ABCD-…

Then start it. This is the command you leave running:

node genosyn-bridge.mjs run

A new Chrome window opens on that computer. That window is the one your AI Employee works in. Sign in there to the sites you listed, and leave the bridge running for as long as you want the browser reachable — it reconnects on its own after a network blip, with backoff.

pair

Exchanges the one-time code for a long-lived bridge token, written to ~/.genosyn/browser-bridge.json with owner-only permissions.

run

Holds the connection open and launches Chrome on the first request. Ctrl-C stops both.

status

Prints what it is paired to, and where the profile and log live.

logout

Deletes the local token. Disconnect the browser in Genosyn too — that is what burns it server-side.

The bridge has no dependencies to install, keeps everything under ~/.genosyn/ ( the Chrome profile, the token, a log), and refuses to talk to a Genosyn served over plain http unless it is on the same machine — a bearer token that opens a channel into a browser has no business crossing a network in the clear.

The allow list is mandatory

Every member browser carries its own list of hosts it may open, in the same syntax as the employee allow list: one host pattern per line, *.notion.so for a domain and its subdomains, # for a comment. The difference is what an empty list means.

The two lists are checked independently and a URL must pass both, so granting an employee your browser can only ever narrow where it may go, never widen it. The list is also pushed down to the bridge and re-checked there, on your machine, before the navigation reaches Chrome — along with a refusal of anything that is not http or https, and of Genosyn's own origin. Edits apply immediately.

The bridge additionally refuses a set of DevTools commands that the browser_* tools never need and that would each take something from a personal machine: writing downloads to your disk, reading or replacing the profile's whole cookie jar, turning off certificate checks, or closing the browser out from under you. It is defence in depth rather than the main boundary — the dedicated profile is that — but the refusal happens on your computer, where a compromised server cannot argue with it.

Using it in a chat

Two things have to be true. The AI Employee needs Browser access on (Settings → Browser on the employee), and you have to grant that employee this browser: open the browser's row in Settings → Browsers and add it under AI Employees allowed to use it. Until you do, nothing can reach it.

Then, in the chat header, the browser picker switches the conversation between Genosyn's browser and any of your own. The choice sticks to that conversation rather than to the next message, and switching mid-thread starts a fresh browser session rather than carrying the old one over. There is deliberately no tool for this: which signed-in browser to drive is a delegation of authority, not a step an employee can take for itself.

Only one session drives a browser at a time. A second one is told the browser is busy and is instructed to ask you rather than quietly using a different browser — the same rule covers every failure here. An employee that cannot reach your machine is told to stop and explain, never to substitute Genosyn's own browser for the one you chose.

Using it in a Routine

Off by default. A Routine fires on a schedule with nobody present, and a laptop asleep at 3am turns every run into a failure you do not see until morning. Tick Let scheduled Routines use this browser on the browser if you want it anyway — the checkbox is on the browser, not on the Routine, because the person who consents to unattended use of a machine is the person who owns it.

Once it is on, the Routine editor offers the browser under Which browser, alongside the browser-access override. Browsers without unattended use are not listed there at all — offering a choice that is designed to fail is worse than not offering it.

With it off, a Run that tries to use the browser is refused rather than re-targeted. With it on, the grant is still re-checked when the Run starts and on every single browser action, so removing a grant stops a Run that is already in flight, not merely the next one.

Approvals default on

Ask me before submitting a form is on when you connect a browser. The pages reachable here are ones a human deliberately signed into, so a submit is worth a look. It works exactly like the employee-level setting described under Browser: browser_submit queues an Approval with the page URL and a one-line summary, and the employee re-fires it with browser_resume once a company owner or admin approves. The approval is bound to the page it was raised on and fires exactly once.

The two settings are a union, not an override. An employee configured without approvals for the unattended container browser does not silently lose them when it is pointed at your machine.

Only you can watch or take over

Live view and take-over work the same as for Genosyn's own browser, with one hard restriction: for a session driving a member browser, only the browser's owner may open the view or take control. Not admins, not company owners. Being able to drive a colleague's signed-in browser would be a larger grant than any role in this product confers, and it is not one that a role should be able to hand out.

Take-over is still the intended answer to a captcha, a 2FA prompt, or any step that wants a human — and here you are already sitting at the machine, so you can also just use the Chrome window directly.

When the laptop sleeps

A closed lid leaves a connection that looks alive for minutes, so the bridge and the App exchange heartbeats and Genosyn gives up on a silent bridge after about seventy seconds. What happens next depends on the timing:

• Between actions. The employee is told the browser is offline, that nothing ran and nothing changed, and that it must not retry or switch browsers — only ask you to start the bridge, or whether to use Genosyn's own browser instead.
• Mid-action. The last action is reported as unverified: it may or may not have completed. The employee is told to summarise what it finished and what is left rather than repeat anything. Genosyn does not replay work it cannot confirm.
• On a Routine. The Run fails loudly. That is the intended outcome, and the reason unattended use is opt-in.

When the machine wakes, the bridge reconnects by itself and the browser comes back online within a few seconds. Idle sessions on a member browser are held far longer than local ones — thirty minutes rather than five — because a human stepping away from their own laptop is normal, and closing their window because of it would not be.

Vault: filling yes, saving no

A granted Vault login still fills normally here: the employee calls browser_fill_vault, Genosyn types the value into the page, and the model never sees plaintext. The origin, item-level Grant, and host-policy checks are unchanged.

If a credential genuinely should be company property, add it in the Vault yourself, or let the employee generate one with create_vault_login in Genosyn's own browser.

Disconnecting

The trash icon on the browser's row disconnects it, and it takes effect immediately rather than at the next session: the bridge token stops working, the bridge socket is dropped, every AI Employee grant on the browser is removed, any conversation or Routine pointed at it falls back to Genosyn's browser, and any session using it right now is closed. The record survives so the audit trail stays intact.

Removing a single employee's grant is the narrower version of the same thing, and is just as immediate. On the computer, stop the bridge and run node genosyn-bridge.mjs logout to delete the local token; delete ~/.genosyn/chrome-profile too if you want the signed-in sessions in that window gone.