How to Use Amp CLI with a Signed-In Browser

To use Amp CLI with a signed-in browser, run Amp locally on the same machine as Tabbit Browser, confirm the tabbit Skill is discoverable, and verify that Tabbit CLI can open the signed-in document in a separate task tab. Then ask Amp to turn the document changes into a local regression checklist and stop at a named draft for human review. An Amp Orb or a Runner is a different execution location, so it will not inherit the browser session on your current desktop by default.

Amp’s current docs list Skills with amp skills list and describe automatic loading based on the request. The 2026 CLI rebuild announcement says user-invoked Skills were removed, so a slash command such as /tabbit is not the current documented route (Amp Skills, Amp, Rebuilt).

Key takeaways

• Use local Amp CLI when the signed-in Tabbit Browser is on the same machine.

• Check the current thread’s Skill list; do not assume that /tabbit works in Amp.

• Amp Skill discovery, Tabbit CLI availability, and browser login are separate checks.

• An Orb or Runner runs in another execution environment unless it is explicitly the machine holding the target browser session.

• Have Amp save a named checklist draft and review each source before sharing it.

First decide where the Amp thread runs

Amp CLI can run an agent locally, in an Orb, or on a connected Runner. The plain amp command opens a local interactive thread by default. An Orb is a remote Amp-managed machine; a Runner is a machine where someone started an Amp runner process. This choice decides which files, commands, and browser instance the thread can reach (Amp CLI guide, Orbs and Runners).

An Orb can use Orb Network Routing for network requests, but network reachability does not copy a local browser profile or its cookies. Amp’s runner docs also describe a desktop hosted by the Runner machine; that is not the desktop where you happened to start a remote CLI command. If you need to know the trade-offs between local and remote browser environments, see local vs. cloud browser agents.

Check the Skill before asking Amp to read a private page

The Tabbit CLI quick start says Tabbit installs a Skill for agents it detects and asks you to verify it by entering /tabbit. That exact slash syntax is supported by some clients, including Qoder CLI, but current Amp CLI docs do not document it. Amp’s Skills page says it scans local and shared Skill locations, including ~/.agents/skills/, and provides amp skills list or Ctrl+O → skills: list to inspect what the current thread can use (Tabbit CLI quick start, Amp Skills).

Check from the same Amp CLI installation and machine that will run the task. An amp skills list call in another shell can show discovered Skill sources, but the docs warn that it does not reload an already running thread. In the current thread, ask Amp to list the Skills available there, use the palette’s skills: list, or ask it to reload Skills. The new Amp CLI automatically selects Skills based on names and descriptions. Its rebuild notes explicitly say user-invoked Skills were removed, so do not type /tabbit or depend on the older skill: invoke palette action (Amp rebuild notes).

Tabbit’s official setup page documents session reuse and shows that the task can continue while the user works elsewhere. A local fixture check in this environment confirmed that a second Tabbit CLI task could read a test page after a separate task established a test login. That check confirms the Tabbit CLI session behavior only; it did not test Amp CLI as an integration.

Make a regression checklist from document changes

Use this pattern when a signed-in release document has changed and QA needs a compact list of pages to recheck. First open the document in Tabbit yourself. In local Amp CLI, ask for a bounded, read-only task and name the output file so it stays a draft.

If the tabbit Skill is available in this local Amp thread, use its instructions for the browser step. Read the signed-in release document that I opened in Tabbit and compare the latest changes with the previous version.

Do not edit the source document, submit a form, or publish anything. For each change, capture the section heading, old wording if visible, new wording, the URL, and the user flow that may need a regression check. Mark missing old wording as unknown.

Save a local file named "release-doc-regression-checklist-draft.md". Include one checklist item per change and a final section called "Needs human review". Stop before sharing or attaching the checklist anywhere.

This prompt illustrates a proposed workflow. It is not a reported Amp + Tabbit CLI test. It is also not a request to let the agent write back to the knowledge base. If your Amp thread does not list the Tabbit Skill, do not proceed as though the browser connection succeeded.

A useful checklist row names the document section, the visible change, the relevant page, the expected behavior, and the result a reviewer should record. Keep the source URL beside every row. The browser agent prompt template helps set those boundaries; the first-task checklist gives a repeatable read-only smoke test.

Review the draft before it becomes release work

Open each source URL in Tabbit and verify that the document changed as the draft says. A regression candidate is only a suggestion until someone confirms that the changed wording affects a user flow. Remove duplicate checks, add an owner or test environment if your team needs them, then move the reviewed items into your normal QA process.

If the goal is browser connection setup, start with the Tabbit CLI guide, connecting an agent to an existing browser, and the Codex session check. The browser task itself may use a CLI or an MCP server; the same-task comparison explains that choice. For a concrete local test site, use the browser validation example or an agent browser CLI tutorial.

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.