A Devin cloud session and Tabbit Browser on your computer are separate environments. Devin documents a Linux virtual machine booted from an environment snapshot and browser authentication in Devin’s own environment. That does not give Devin access to local Tabbit cookies. Use a supported local handoff for a signed-in local site.
Decide which environment owns the session
| Task | Suitable route | Session boundary |
|---|---|---|
| Public page | Devin’s documented browser, if enabled | Devin environment only |
| Page signed in on your computer | Local Tabbit Browser and Tabbit CLI | Selected local profile, checked by a person |
| Cloud task needs local-only page | Handoff URL and fields to local agent/person | Do not send cookies, tokens, or passwords |
| Change affects a live system | Stop at a named draft | Human checks before submit or publish |
Check current Devin environment docs and browser authentication docs. New Devin sessions boot from snapshots; do not assume a remote runtime can reach your computer.
Create a concrete local handoff
Ask Devin for a handoff note with the exact URL, fields to read, draft name, and review checkpoint. A local agent can then verify its Tabbit skill, CLI connection, and site login separately.
Prepare a local browser handoff. Check [exact URL] against commit [hash].
Capture only the visible page title, version, and release date. Save a
draft named "Devin handoff - release review R-204" with source URL and
any mismatch. Do not include credentials. Do not submit or publish.
Stop for human review.This is a suggested handoff, not a claim that Devin connected to your local browser. Review the named draft in Tabbit while the local agent uses a separate task tab.
Decision
Use Devin’s browser for its configured environment. Use Tabbit Browser and Tabbit CLI for a local signed-in browser task when the agent runs locally. If Devin runs remotely, hand the work to a local agent or person and review before changing the site.
A small first check
Install Tabbit Browser, follow the Tabbit CLI quick start, sign into the target site yourself, and ask for a read-only task in a new Tabbit task tab. Keep working in your regular browser tabs while it runs.
Use the Tabbit instructions available to this agent. If unavailable, stop.
Open [exact authorized URL] in a separate task tab. Return the page title
and [one visible field]. Do not edit, submit, send, delete, or publish.| Check | Passing evidence | If it fails |
|---|---|---|
| Skill | The selected agent can read the installed Tabbit instructions | Check its skill discovery mechanism; do not assume /tabbit support |
| CLI | Local version or bounded diagnose command completes | Check shell access and local permissions |
| Site | Page title and visible field match a human check | Sign in manually in the intended Tabbit profile |
For related guidance, see Tabbit CLI guide, connect an agent to an existing browser, first browser-agent task checklist, browser MCP versus CLI, Codex setup example, agentic browser overview, web search versus browser control, and browser-agent security.
FAQ
Does the client automatically discover /tabbit?
Do not assume it does. Check whether the selected agent can discover the installed Tabbit instructions.
Does a successful CLI diagnosis mean the site is signed in?
No. It checks the launcher connection. Verify the exact page in the intended browser profile.
Can a remote agent use my local Tabbit session?
Only through a supported local handoff. A remote process cannot directly read your local browser profile.
What is a safe first task?
Read one authorized page and return a title plus a visible field. Stop before any write action.
Should the agent publish its draft?
No. Keep a named draft and review it against the source page before any change.