How to Use Factory Droid with a Signed-In Browser

To turn a test case into evidence from a page where you are already signed in, run Factory Droid locally, confirm it has found the Tabbit skill, and have it call Tabbit CLI for a read-only check. Keep the browser report as a named draft and stop before any form submission. This handoff lets you review the URL, visible result, and test ID before Droid proceeds.

One Reddit user reported that a Droid Mission had run for 12 hours and increased their plan spend. Another said they liked trying Droid but were not switching from their existing coding assistant. These are individual reports, not measurements; they are a reminder to keep the browser task small and judge the handoff on its own. (Mission discussion, Droid trial discussion)

Droid CLI is Factory’s terminal interface for project context, approvals, skills, and headless work. Factory documents /skills for managing discovered skills and project skills under .factory/skills/. For a browser task that depends on your local signed-in session, use local Droid CLI and the local Tabbit Browser. A remote agent’s browser session is a separate environment unless a supported handoff is documented.

Key takeaways

• Start with droid in the project you want Droid to understand, then check its discovered skills with /skills.

• The Tabbit skill’s presence, the local CLI launcher’s reachability, and the website’s login state are three separate checks.

• Keep autonomy at off for the first read-only check; review any proposed write operation yourself.

• Use a test case ID and expected result as the task input, not a dump of account data or secrets.

• Save an evidence draft with a stable name, then inspect it before authorizing a site change.

Pick the right environment for the browser check

Factory’s Droid CLI overview describes a terminal runtime beside your shell, editor, and tests. Its quickstart shows a scoped task with a proposed diff and approval checkpoint. Neither document establishes that a remote session can see the browser profile on your computer. When you need the existing local login, keep the browser work local.

Make the skill visible before using it

Start Droid in the project directory:

droid

At the prompt, run:

/skills

Check that tabbit is enabled and note which copy is effective. Factory documents personal skills at ~/.factory/skills/<name>/SKILL.md, project skills at <repo>/.factory/skills/<name>/SKILL.md, and compatibility support for ~/.agents/skills/**/SKILL.md. It also notes that a project or organization copy can override another version. If you installed the skill while Droid was already open, start a new session and inspect /skills again. Invoke /tabbit only if the skill appears as a user-invocable command; otherwise ask Droid to use the discovered Tabbit skill by name.

Factory’s Skills reference documents discovery, enablement, scope, and the /skills manager. This check answers “does Droid know the instructions?” It does not answer “can this computer reach Tabbit?”

Confirm local Tabbit reachability

Open Tabbit Browser, then check its installed CLI from a terminal:

$HOME/.local/bin/tabbit-cli diagnose

If the command cannot find the browser, stop here and repair the local Tabbit connection. If it succeeds, ask Droid to run the same read-only diagnostic and summarize only controller status and browser availability. Do not enable broad unattended permissions just to test the connection. Factory documents autonomy modes and organization-level controls separately; its settings reference lists new-session autonomy as off by default.

Next, confirm the actual target site session. Sign in yourself in Tabbit, open the page in question, and ask Droid to return the page title, URL, test case ID, and visible status. Do not include cookies, tokens, account IDs, or form contents in the prompt. If the browser opens but the site redirects to login, the skill and launcher may work while the web session does not.

Turn a test case into a reviewable draft

For a test ticket, copy only the non-sensitive fields needed to reproduce it: case ID, page URL, expected visible result, and the output filename. Then prompt Droid with a clear stop point:

Use the discovered Tabbit skill from this local Droid CLI session.
Open the acceptance page at https://staging.example.test/release-notes in my existing Tabbit Browser session.
Read the page title and the visible status for test case QA-104.
Do not submit forms, change settings, or copy account data.
Save a short report as droid-qa-104-review.md with: case ID, URL, observed title, observed status, expected status, and pass/fail/needs-human-check.
Show me the draft and stop. Do not make a site change.

The sample URL and QA-104 are illustrative fixtures, not a real test or a claimed integration result. Replace them with your own non-sensitive test data. Read the task plan and approvals, check the saved report, and compare its page title and status to the live page. If the report says needs-human-check, use the browser yourself rather than asking Droid to infer the missing state.

Tabbit CLI gives its browser work a separate task tab, so you can keep using other tabs while the check runs. A local fixture check on November 9, 2026, read a protected page after a test cookie was set, in a second task tab. It confirms session reuse for that Tabbit environment and fixture only. It does not verify Factory Droid calling Tabbit; the prompt above is a proposed handoff workflow. Keep that distinction in the report.

Decide what happens after review

If the draft accurately captures the page and the next step is read-only, ask Droid to continue with a bounded comparison or summary. If the task needs to submit a form or change a record, review the exact action and destination first, then approve that individual step. Do not ask Droid Exec or another remote runner to reuse a desktop login unless that connection is documented and configured.

This separation is useful for browser agent work, reusing a browser login, and first task setup. A prompt template can carry the exact stop condition into a repeatable run. For broader browser research, CMS draft work, or web data extraction, make the expected output fields part of the handoff. The Tabbit CLI setup guide covers local installation, and the Playwright MCP guide covers a separate integration path. A remote CI run can still prepare a checklist or expected values; a person or local agent must complete the browser check when only the local profile has access.

Secholar.L

Growth & Content at Tabbit

Secholar.L writes hands-on guides about AI browsers and agent workflows, comparing tools with real research and citing verifiable sources.