A local goose workflow can read a signed-in website through Tabbit Browser when goose can load the Tabbit Skill and run Tabbit CLI on the same machine; you still need to verify the site login and target page yourself. One r/LocalLLaMA user who built an MCP Chrome driver for goose said the agent sometimes "invent URLs that don't exist." That is why this weekly report recipe asks goose to return links and stop at a review draft, instead of treating a fluent summary as proof. Read the original discussion.
Key takeaways
Use a goose Skill to teach the client how to call a tool. Use a Recipe to save a repeatable workflow.
Confirm three things separately: goose sees the Skill, its local command tool can reach Tabbit CLI, and the target site is already signed in inside Tabbit Browser.
Use a read-only first run. Ask for the page title, reporting period and workspace before collecting facts.
Keep source URLs next to every summary item and stop at a named draft for review.
A Docker or remote goose process does not automatically share your host browser or command line.
Goose pieces at a glance
| Piece | What it does | What to verify |
|---|---|---|
| Skill | Supplies reusable instructions and supporting files. Goose lists them with goose skills list and loads one with /skills <name>. | The session lists tabbit after startup. |
| Recipe | Packages a prompt, instructions, tool extensions and optional provider/model settings into a runnable workflow. | The selected extensions include the tools the task needs. Review the recipe before trusting it. |
| Local command tool | Runs the Tabbit CLI launcher. | It runs on the same host as Tabbit, and tabbit-cli diagnose can see the browser. |
| Website session | Supplies the site's logged-in state. | Tabbit shows the expected account, workspace and report page. |
Goose documents Skills as reusable instructions, and gives goose skills list plus /skills <name> as discovery and loading routes. Its browser-use Skill can be installed with browser-use skill install, but that is a distinct browser workflow. Goose Recipes package instructions, prompts, extensions and optional model/provider settings. Neither primitive proves that a local CLI is reachable or grants access to a logged-in site. Goose Skills documentation · Goose Recipes documentation.
If you need a broader primer, see the Tabbit CLI guide, how an agent connects to an existing browser, and the browser MCP vs CLI comparison. For client setup background, see the Codex Tabbit CLI setup guide.
Check the three connections before asking for a report
1. Check Skill discovery in goose
Start a new goose session after installing the Tabbit Skill. Run goose skills list in a terminal or enter /skills in the CLI. If the Skill appears as tabbit, load it with /skills tabbit. On macOS, the documented agent-readable file is usually ~/.agents/skills/tabbit/SKILL.md; inspect the instructions for the supported launcher and task syntax. Do not assume that typing /tabbit is a universal goose command. Goose's documented named-skill syntax is /skills <name>.
For comparison, the official goose browser-use Skill is installed with browser-use skill install. That installs the upstream browser-use workflow. It does not establish a Tabbit connection. See why a browser MCP may connect but expose no tools if your selected connector is present but cannot act.
2. Check local command access
The Tabbit Skill tells goose how to call the local CLI. Goose also needs a terminal or developer tool allowed to run that command. Try a read-only diagnostic first. If goose runs in Docker, over SSH, or on a hosted runner, its command runs in that environment, not automatically on your laptop. Use a supported local handoff if the runtime is remote.
The goose Recipe can select an extension set and even a model/provider. Pick only a provider and model already configured in your goose installation. Check the active setup with goose configure; do not copy a model name from a recipe and assume it is available in your account.
3. Check the browser session
Sign in to the reporting website in Tabbit Browser. Then ask goose to identify the page without changing it. Confirm the workspace, report period and visible title. An agent that reaches the right hostname can still be in the wrong account, an expired session or a login screen.
The Tabbit quick start describes this local pattern: install and start Tabbit, sign into the required site in Tabbit, confirm the Skill is visible to the agent, then issue the browser task. Its local fixture check in this assignment verified that a second Tabbit CLI task could read a page after a short-lived test login had been added. It did not test goose itself or prove that any remote provider can reach that browser. Tabbit CLI quick start. For connection modes and profile boundaries, read the existing-browser guide.
Build a weekly report Recipe with a human checkpoint
A Recipe helps when the task repeats each week and the report structure stays stable. Keep the source site, date range and output format as parameters. Avoid putting passwords, cookies or other secrets in the recipe file.
Example starting prompt:
Use the tabbit Skill and the local Tabbit CLI. Open the signed-in weekly status report for {{ week }}.
Read-only task. First return the page title, workspace name and visible date range. Stop if any value differs from the request or if a sign-in, MFA or CAPTCHA screen appears. Do not change filters or click save.
For each report item, return:
- the exact item title
- its visible status
- one sentence describing the change
- the source URL
Create a draft titled "Weekly report: {{ week }}: review first". Keep all source URLs beside the related items. Do not publish, send or update the source system. End with a review checklist for dates, names and missing links.The double braces above are Goose Recipe parameter placeholders. When you save this as a Recipe, define week as a required parameter, choose the local command extension, and leave model/provider on a configuration you have already verified. Goose's recipe guide supports parameters and a review step before a Recipe runs. A Recipe is a saved workflow, not permission to skip the user's check. Recipe parameters and run flow.
A practical workflow: Tabbit Browser plus goose
The case here is a weekly status report that lives behind a login. The task has a clear reading goal, and the human already has the correct report open in Tabbit. Keep the browser operation narrow: read the visible status rows, preserve their links, and draft a report for review.
A Reddit user described a self-built goose browser bridge and noted it could make up URLs when confused. Another local-model user said browser-use felt "hit or miss" and needed clear instructions and tinkering. These are individual experiences, not current product tests. They support a simple design choice: require a visible page check and source URLs before the model summarizes anything. Original goose discussion.
Keep goose's run in a separate task space and leave the source report open. The Tabbit quick start says a user can work in other windows while a CLI task runs. When goose returns Weekly report: review first, open each cited link, check the date range, and compare the draft with the page. Only then copy it into a shared document or publish it. For examples of safe draft handoffs, see the browser-agent CMS draft workflow and the first-task checklist.
Diagnose the failure before retrying
| Symptom | Check | Safe next step |
|---|---|---|
/skills tabbit is unknown | Is the Skill installed in a directory goose scans? Was the session restarted? | Confirm goose skills list, then start a fresh session. |
| CLI command is not found | Which host or container is running goose? Is the Tabbit launcher installed there? | Install or hand off to the local runner; do not assume an SSH or Docker process can reach the desktop. |
| Page shows sign-in or the wrong workspace | Is the intended account signed in in Tabbit? Did the session expire? | Stop, complete sign-in yourself, then repeat the read-only page check. |
| Summary includes broken or guessed links | Did goose return the final URL from each page? | Open each link and drop any item that cannot be matched to the report. |
| A page asks for a CAPTCHA or MFA | The site is requesting a human verification step. | Stop and complete it yourself. Do not ask the agent to bypass it. |
| A Recipe chooses an unavailable model | Is that provider/model configured and authenticated for this goose installation? | Remove the override or select a verified local configuration. |
A few browser-agent setup checks and local web-app validation steps can help isolate whether the failure sits in goose, the CLI or the page itself. For access boundaries, see browser-agent security risks.
Verdict
For a recurring browser report, keep the reusable instructions in a goose Recipe and use a Skill to explain how goose reaches Tabbit CLI. Choose this setup only when goose's command tool and Tabbit run on the same reachable machine. For a genuinely signed-in browser task, Tabbit Browser plus its CLI is the direct route; verify the site session, ask goose for a source-linked draft, and keep the final review with a person.
Related guides
FAQ
How do I use a browser with goose?
Give goose a browser tool or a local browser command it can reach. For a signed-in Tabbit session, first confirm that goose can load the Tabbit Skill and run the installed Tabbit CLI on the same machine as Tabbit Browser.
Is a goose Recipe the same as a Skill?
No. A Skill provides reusable instructions and supporting files. A Recipe packages a runnable workflow, prompt, selected extensions, and optional model settings. A Recipe does not grant browser or shell access by itself.
Can goose reuse my website login?
It can only use a session that the browser tool can reach. With Tabbit, sign in to the site in Tabbit Browser, then confirm the page and account before asking goose to read it. A login can expire or require another verification step.
Why does goose say it cannot run the Tabbit command?
Check that the `tabbit` Skill is discovered, the local terminal tool is enabled, and the Tabbit CLI launcher is installed on the machine where goose runs. A Docker or remote shell may not see a host browser or its CLI.
Should I install goose's browser-use Skill too?
Install it if you want that Skill's own browser-use workflow. Do not assume it connects to Tabbit Browser. To use Tabbit, load the Tabbit Skill and confirm the local CLI call reaches the intended Tabbit instance.
Can I let goose publish the report automatically?
Keep the first workflow read-only and stop at a named draft. Check the source links, date range, account and summary yourself before sharing or publishing anything.