How to use TRAE SOLO with a signed-in browser

For a signed-in browser task, use TRAE SOLO Desktop only after confirming its task can run the Tabbit CLI on the same computer as Tabbit Browser. SOLO Web runs in the cloud, so it cannot use your desktop's browser session just because you opened it in a browser. The built-in preview is meant for reviewing work inside a project; it is not proof that the agent can read your separate, logged-in Tabbit window. If the client cannot reach the local launcher, let SOLO prepare a checklist and perform the browser step locally.

TRAE's current product material distinguishes Desktop and Web: Desktop opens local project files, while Web runs tasks in the cloud. Its changelog also describes selecting elements in the built-in browser preview. That supports preview review, not a claim of native Tabbit Browser access. Community feedback is mixed: one user valued pinning the preview so files would not replace it; another asked whether SOLO could interact with the preview to test pages and read console logs. Those posts point to the same practical distinction: a visible preview is helpful, but you still need to verify the browser route. Positive workflow · interaction question.

Key takeaways

• SOLO Desktop is the candidate for a same-computer local browser workflow; verify local command access in the installed version.

• SOLO Web runs in the cloud. Treat its built-in browser or preview as separate from your desktop Tabbit profile unless TRAE documents and you verify a local handoff.

• A built-in project preview can help inspect a generated page, but it does not prove an external site's authenticated state.

• Keep the first task read-only. Save an evidence note, then review it in your own browser before sharing or changing data.

Choose an execution location

The TRAE SOLO overview describes its built-in preview as a development tool for interacting with page elements and checking console logs. TRAE's SOLO launch note describes Desktop's access to local files and Web's cloud execution. Availability and labels can vary by client version and region, so check the app you actually have.

Check whether Desktop can run the local skill

1. Open Tabbit Browser and sign in to the site yourself. Keep a harmless page ready, such as a support case summary or a status page you may read.

2. Open TRAE SOLO Desktop, choose the local project/workspace, and confirm the task's Terminal and Skills controls are available. TRAE's separate IDE changelog says .agents/skills loading is supported in the IDE; do not assume that statement applies to every SOLO edition.

3. Install or expose the Tabbit skill only if the SOLO client accepts that skill root. Check its skill picker and local command permissions. If /tabbit is absent or the command is not callable, stop and use the checklist handoff below.

4. If those checks pass, run one read-only Tabbit task and verify the target URL, visible title, and site login in the task tab.

The Tabbit CLI complete guide covers the local bridge; connecting an agent to an existing browser explains browser-session boundaries. Use the first-task checklist to check the launcher and login separately. The MCP vs CLI guide compares ways to connect local agents.

Make a local handoff from SOLO Web

When the task is in SOLO Web, do not ask it to reach into a local browser. Ask for a bounded evidence checklist. Then open Tabbit Browser yourself, sign in, and either run the checklist with a local client that supports Tabbit CLI or inspect the page manually.

Create a draft named "Incident evidence checklist, draft 01".
This is a preparation task only. You are running in TRAE SOLO Web.
Do not claim access to my desktop browser or any signed-in website.

Prepare a checklist for a human or local agent to verify an incident page:
- exact page URL to open (leave as a placeholder if I have not supplied it)
- page title and incident ID to record
- visible status label, timestamp, and one source excerpt
- screenshot region to capture
- fields that must not be copied into the draft (personal data, tokens, email addresses)
- a final "Human review before sharing" checkpoint

Do not sign in, submit forms, or change incident state. Mark every value not
provided by me as "to verify in the browser".

Expected output is a checklist with no invented values. For a local Desktop task that has passed the skill and launcher checks, adapt the prompt to read one authorized page and attach the source URL. An illustrative test fixture may use the page title Release notes review and record GEO-104; those are sample values, not a real incident. The session reuse guide explains the browser login boundary, while the Codex setup guide is a verified local-client pattern.

Keep preview and production evidence separate

A Reddit thread about SOLO's preview includes both a user who likes pinning the preview and another who asks whether the agent can interact with it. That disagreement is why the prompt names the expected output and asks for evidence rather than a simple “done.” The local Tabbit CLI test fixture in this assignment verified only that a separate task could read a page after a test login was set; it does not verify TRAE integration.

If local Desktop can run the CLI, use an isolated task tab and keep the source page visible for review. If only Web is available, take the local step yourself or use a supported local agent. Read browser-agent security risks, browser tools for agents, and Tabbit Browser installation steps before expanding a read-only task. Start by testing the local launcher; do not treat the Desktop label or a preview pane as proof of browser connectivity.

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.