Zed’s Agent Panel can host Zed Agent or an ACP External Agent, but the panel is not the browser connection. Verify which process is running, whether that process can use the Tabbit skill and local CLI, and whether the target site is signed in inside Tabbit Browser.
Choose the actual agent process
Zed’s Agent Panel docs describe an interface for agents that read, write, and run project code. External Agents says ACP agents run in their own process and usually own runtime, authentication, model, and tools. Zed Agent instead uses the providers configured in Zed. ACP does not itself grant browser access.
| Zed path | Runtime | Check before using Tabbit CLI |
|---|---|---|
| Zed Agent | Zed-managed process | Local command access and available tools |
| ACP External Agent | Separate agent process | That agent’s skill discovery, shell, auth, and permissions |
| Terminal thread | Local terminal | PATH, CLI install, and shell policy |
Turn page context into a review draft
For a code change that needs a documentation check, ask a local Tabbit task to collect the visible title, update date, and one proposed clarification into a named draft. Compare it against the page and your code diff. Keep the draft local and do not publish. This is an illustrative workflow, not a tested Zed integration.
Use the Tabbit instructions available to this Zed agent. If unavailable, stop.
Read [exact documentation URL]. Create a local draft named "Zed release
note review - DOC-104" with the visible title, update date, and one
proposed clarification. Include the source URL. Do not edit or publish.
Show the full draft for review in my regular Tabbit tab.Decision
Use Tabbit Browser plus Tabbit CLI when the selected Zed agent runs locally and can use the launcher. If the selected thread is remote, establish a supported local handoff first. A Zed panel does not inherit another browser’s login.
A small first check
Install Tabbit Browser, follow the Tabbit CLI quick start, sign into the target site yourself, and ask for a read-only task in a new Tabbit task tab. Keep working in your regular browser tabs while it runs.
Use the Tabbit instructions available to this agent. If unavailable, stop.
Open [exact authorized URL] in a separate task tab. Return the page title
and [one visible field]. Do not edit, submit, send, delete, or publish.| Check | Passing evidence | If it fails |
|---|---|---|
| Skill | The selected agent can read the installed Tabbit instructions | Check its skill discovery mechanism; do not assume /tabbit support |
| CLI | Local version or bounded diagnose command completes | Check shell access and local permissions |
| Site | Page title and visible field match a human check | Sign in manually in the intended Tabbit profile |
For related guidance, see Tabbit CLI guide, connect an agent to an existing browser, first browser-agent task checklist, browser MCP versus CLI, Codex setup example, agentic browser overview, web search versus browser control, and browser-agent security.
FAQ
Does the client automatically discover /tabbit?
Do not assume it does. Check whether the selected agent can discover the installed Tabbit instructions.
Does a successful CLI diagnosis mean the site is signed in?
No. It checks the launcher connection. Verify the exact page in the intended browser profile.
Can a remote agent use my local Tabbit session?
Only through a supported local handoff. A remote process cannot directly read your local browser profile.
What is a safe first task?
Read one authorized page and return a title plus a visible field. Stop before any write action.
Should the agent publish its draft?
No. Keep a named draft and review it against the source page before any change.