Use OpenHands with a signed-in browser

OpenHands can work with a local project workspace without gaining access to the browser running on your host. For a signed-in preview page, first identify the OpenHands runtime: local workspace access, a sandbox/container, and a remote deployment are different boundaries. If your agent process and Tabbit CLI can run on the same supported host, evaluate a local Tabbit connection and verify it with a read-only page check. A mounted project directory does not prove that browser sockets, cookies, or login state are available.

An OpenHands community member describes using “Playwright CLI for isolated browser testing”; a commenter calls the separation a “cleaner trust boundary.” These are community workflow reports, not proof that OpenHands can reach Tabbit. Read the original discussion.

For a code fix followed by a preview check, keep the two steps separate. OpenHands can prepare the code change. A local browser task can inspect the signed-in preview and save preview-184-review.md for a person to check. This is a proposed workflow, not a tested OpenHands integration.

Key takeaways

• “Local Workspace” describes file access; it does not guarantee host-process execution or access to your browser profile.

• OpenHands may run commands inside a sandbox or container. Verify where the runtime and CLI process actually run.

• Tabbit CLI is a candidate only when its launcher can reach the intended Tabbit instance from the configured host.

• A container must have an explicit, supported local bridge. Do not infer one from workspace mounts or networking assumptions.

• Save preview observations in a named report and keep publishing or form submission behind a human review.

First identify the OpenHands environment

OpenHands official settings documentation exposes sandbox and runtime settings. The GitHub Action guide describes a custom sandbox image. That is why “local workspace” should not be shortened to “the agent can use my local browser.” The actual runtime is the deciding fact.

Check the local bridge in order

1. Confirm that the OpenHands agent process and the Tabbit CLI launcher run on the same host, or document the supported path between them.

2. Confirm the client can load the Tabbit skill or explicitly invoke its local CLI. /tabbit is only valid if your OpenHands client exposes named skill commands; otherwise use the documented skill mechanism.

3. Ask Tabbit CLI to inspect the available browser instance. Select the intended one rather than guessing which process or profile is active.

4. Open the preview page and verify the visible title, signed-in account, and build identifier. Stop if the page asks you to sign in or shows another account.

5. Run a read-only task first. Check that the result reports the expected page content before trying any changes.

A local project path and a local browser are separate resources. Network access from a container, where available, is also not the same as access to a desktop browser session. Do not mount a profile directory or copy cookies as a shortcut.

Use a named preview review

For the local preview scenario, ask OpenHands to finish the code change first. Then use the local browser task to read the preview and create preview-184-review.md. Include the route, build identifier, visible heading, expected behavior, observed behavior, and unresolved items. Keep the report local until a person confirms it matches the intended build.

Example prompt for a local OpenHands client that can invoke the Tabbit skill:

Use the local Tabbit skill only if this OpenHands runtime can reach the Tabbit CLI on this host.
If this task is running in a container or remote runtime without a documented local bridge, stop and prepare a manual checklist instead.
Open the signed-in preview in the selected Tabbit browser instance.
Create a separate task named "preview-184-review".
Inspect /settings/profile?preview=184 and verify the build label and visible heading.
Do not submit forms, save settings, or publish.
Save preview-184-review.md with expected versus observed behavior, evidence, and unresolved checks.
Stop for human review.

The prompt includes an explicit stop condition because a preview can contain production-like controls. Treat screenshots and fixture data as examples unless the deployed environment is confirmed.

When OpenHands cannot reach Tabbit

If the runtime is hosted or containerized without a documented host bridge, have OpenHands produce a local test checklist or read-only script. A person can run the browser check locally and return only the results needed to fix the code. Avoid sending login cookies, browser profile directories, or customer data into the container.

The Tabbit-side workflow is documented in the CLI setup guide, existing browser connection guide, and signed-in session explainer. For generic check steps, see the first task checklist, browser MCP vs CLI comparison, browser session basics, local app validation workflow, and Codex setup example. These pages explain Tabbit or browser testing; they do not establish OpenHands host access.

A practical option: Tabbit with a local OpenHands runtime

Tabbit is worth evaluating when a preview is already open in the same computer’s browser and the OpenHands runtime can invoke the local launcher. Open the preview yourself in Tabbit, check the account, and let the browser task read a separate tab. You can continue editing code or reviewing another page in the other tabs.

This depends on a verified same-host connection. A Docker container with access to the repository is not enough. The OpenHands deployment must have an explicitly supported route to the Tabbit CLI, and Tabbit CLI must select the intended browser. If either check fails, use a manual review report instead.

Choose the handoff by runtime

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.