How to use Claude Opus 5.5 with a signed-in browser

For a local Claude Opus 5.5 workflow that edits an already signed-in page, install Tabbit Browser and connect Claude Code through Tabbit CLI. Select the full Opus 5.5 model name, confirm the CLI is reachable, and sign in to the shared document in Tabbit yourself. Then let the agent prepare a named draft and stop at a visible review checkpoint, such as Launch FAQ v3 (Needs review).

One r/ClaudeCode user described queueing playtest issues and asking for the next batch only after reviewing the previous one. That is a useful handoff pattern, though the report concerns a browser game rather than a shared business document. Original post.

Claude Opus 5.5 is not a browser connection. Anthropic documents it as selectable in Claude Code, but the client still needs a tool that can reach the browser profile. Anthropic's separate Claude for Chrome product is another option when you want Claude to work in Chrome under its own site permissions. These routes do not share a browser profile by default. The Opus 5.5 review covers the model itself; this guide focuses on who can reach your signed-in document and where review belongs.

Key takeaways

• In Claude Code, select claude-opus-5-5 and verify the active model with /status.

• Install the Tabbit skill in Claude Code and invoke /tabbit only after the client lists it. If it is absent, check skill discovery before debugging the browser.

• Sign in to the target document in Tabbit Browser. A Chrome login is not automatically a Tabbit login.

• Use a local client for the edit. A cloud workspace needs a separate supported local handoff.

• Save a named draft with a visible Needs review state. Review the changed text in the shared document before anyone publishes or sends it.

Choose a browser route before editing

Claude Code's model selector and browser integration solve different problems. Anthropic's model configuration guide says to select Opus 5.5 with /model or claude --model claude-opus-5-5, then check the active session with /status. The same guide lists Opus 5.5 as supported. The provider and account still determine whether the selection works for you. Anthropic model configuration.

Anthropic describes Claude in Chrome as a browser product with site permissions and confirmation for actions such as publishing, purchasing, or sharing personal data. Its browser safety article also explains that browser instructions can be malicious. Tabbit CLI is a separate local connection. It uses the selected Tabbit Browser environment; it does not import Chrome cookies. For details on Claude Code permissions, check the prompts and action boundaries of the client you choose.

Set up Claude Code and Tabbit separately

1. Confirm your client is Claude Code and select Opus 5.5. Anthropic documents both claude --model claude-opus-5-5 for a terminal session and the /model picker. Run /status to check the active model. If your provider does not offer the full model ID, stop here and resolve model access first.

2. Install the Tabbit skill in Claude Code's skill directory. Start Tabbit Browser first so the CLI can use its local browser connection, then restart Claude Code if needed for skill discovery.

3. Check whether /tabbit appears in the client's skill list. If not, check the installed skill path and Claude Code's skill discovery. Do not treat the skill being present on disk as proof the local launcher is reachable.

4. Run the CLI connection check and use a harmless page read. The local client, launcher, and browser are separate layers. The Claude Code + Tabbit CLI setup covers this client-specific setup.

5. Open the shared document in Tabbit and sign in yourself. Confirm the exact document title and its current version before asking for changes.

A Reddit user describing a Claude Code browser game workflow kept the owner in the loop: they played builds, queued changes, then reviewed a batch before asking for the next one. That is a useful pattern for shared documents too. The community report is about building a game, not editing a business document, so treat it as workflow evidence rather than proof of model or product behavior. Original r/ClaudeCode post.

Revise a shared document and leave a clear checkpoint

Use a test document or one you are authorized to edit. Name the draft before the agent starts. Ask it to make bounded changes, preserve existing text that is outside scope, and leave the shared document in a review state. The following prompt is an illustrative workflow, not a report of a completed edit.

Use Tabbit CLI in the current Tabbit Browser profile.
Open the shared document "Launch FAQ" and verify its current version before editing.

Prepare a draft named "Launch FAQ v3". Apply the editor notes below only to
these sections: Eligibility, Setup, and Troubleshooting.

Editor notes:
- Define eligibility in one sentence.
- Keep the setup steps in the order users perform them.
- Add a source URL beside every changed product claim.
- Preserve unrelated sections and do not invent missing details.

Do not publish, send, share externally, or change permissions.
After editing, set the document's visible status to "Needs review" if the
application supports draft labels. Otherwise leave it unsent and report that
there is no visible review label.

Return the document title, version label, changed section names, review status,
and source URLs. Stop for my review.

Expected output should identify Launch FAQ, Launch FAQ v3, the three changed sections, and Needs review. These are example labels. If the application does not show a version or review state, the agent must say so rather than inventing one. A second person can then inspect the specific changes in the shared document. The Reddit community has also described staged review: a user said they split browser video work into four or five steps and reviewed each one rather than accepting one large result. That post is an individual workflow report, not a claim about all Opus 5.5 tasks. Original r/SaaS thread.

Before approval, compare the changed sections with the editor notes, click every source URL, and check that the draft remains unsent. The author's final check should cover the page title, version, status, and any changed claims. If the content affects policy, customer commitments, legal text, or access controls, keep the human responsible for the final decision.

What to do if the routes are confused

• Opus 5.5 is not selectable. Confirm your Claude Code version, provider, and account. The Anthropic model guide describes the selector but cannot grant account access.

• /tabbit is missing. Check the Claude Code skill path and discovery first. The skill command is a client entry point, not a browser connection.

• The CLI cannot launch. Check the local installation and client permission to run it. This is separate from the selected model.

• Tabbit shows a sign-in page. Sign in manually in the selected Tabbit profile. A login in Chrome or a cloud workspace does not establish a Tabbit session.

• The agent edited the wrong version. Stop and restore the intended version yourself if needed. Confirm title and version before resuming.

• No visible review state exists. Leave the draft unsent and tell the editor where the changes appear. Do not claim a review label was saved.

For login-session boundaries, see connect an agent to an existing browser and reuse a signed-in browser session. For alternative connection choices, read browser MCP versus CLI, Claude Code controlling Chrome, and Claude Code with Playwright MCP. Keep a visible checkpoint between drafting and publishing.

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.