Use Aider with a signed-in browser

Aider can read a webpage with /web and run a local shell command with /run, but those commands do different jobs. /web https://… scrapes page content into the coding chat; it does not control your signed-in browser. /run can invoke a local Tabbit CLI command if Aider and the launcher share a supported host, but browser control still needs the Tabbit skill/CLI route and an explicit connection check.

In a recent browser-automation discussion, one user reported “Sessions dying because two things touched the same account.” Another described a bot still “working” on a login page after the session expired. These are general browser-agent reports, not Aider-specific tests. Read the original discussion.

For a page acceptance check that should become a Git patch, let the browser step produce release-63-browser-review.md. Give that report to Aider, ask it to propose a focused diff, then inspect the diff before running your usual tests. This is an illustrative handoff, not a verified Aider integration.

Key takeaways

• /web reads URL content; it is not a browser session and cannot reuse a page login by itself.

• /run executes a shell command. It can be the user-controlled handoff to local Tabbit CLI, not proof of built-in browser automation.

• Aider’s documented slash commands do not establish a native /tabbit command. Check the installed client’s skill support before using that syntax.

• If the Aider process runs remotely, it needs a separately supported bridge to reach a browser on your computer.

• Save browser observations in a named report and let Aider prepare a patch from that evidence. A person reviews the diff and approves any external action.

Pick the right Aider command

Aider’s official command reference lists /web and /run separately. Its web guide describes URL scraping, while the /run guide describes shell execution. Its web guide describes scraping a URL, while its /run guide describes executing a command and optionally sharing output. Neither statement means a remote or local Aider session has access to a Tabbit profile.

Connect the local browser only when you can verify it

Use a Tabbit browser path when the page’s current login or visible application state matters. Start by checking how this Aider process runs. If it is local, inspect the installed Tabbit skill instructions and confirm the launcher is reachable. If a named skill is supported, use its documented syntax; do not assume Aider recognizes /tabbit just because the skill file exists.

If the local Aider setup can run commands, a user-controlled check might look like this:

/run tabbit-cli diagnose

Use the actual launcher path from the installed Tabbit skill. Read the result and confirm the selected Tabbit instance before opening a work page. If Aider cannot run the launcher, stop and run the Tabbit task yourself or hand it to a local agent that supports the skill. Do not paste passwords, cookies, or browser data into Aider.

Then sign in to the target site in the intended Tabbit profile. The CLI session and the website login are separate: a working launcher is not proof that the right account is open. The Tabbit CLI quick start describes installing Tabbit, signing into the site, and connecting a supported local agent.

Turn page evidence into a focused patch

1. Open the intended preview in Tabbit, verify its build label and account, and create a separate task named "release-63-browser-review".

2. Save a named report as release-63-browser-review.md. Include route, expected behavior, observed behavior, a short evidence excerpt, and unresolved checks.

3. Add the report to Aider with /add release-63-browser-review.md.

4. Ask Aider to propose a patch limited to the observed defect. Keep the change in the diff for review.

5. Inspect the diff yourself. Run the project’s normal checks only after you agree with the proposed change.

6. Recheck the page after the patch. Do not let the report itself trigger a form submission or publication.

Example instruction for Aider after the report exists:

Read release-63-browser-review.md. Propose a small code diff for the observed preview defect only.
Do not run shell commands, edit deployment settings, publish, or commit.
List the files you would change and explain how each change maps to the report evidence.
Stop and wait for my review.

The browser report is the evidence; Aider’s summary is not a substitute for it. If the report does not identify a reproducible page state, ask for another check before making a code change.

If the Aider process is remote

A remote Aider process may fetch public pages or work in its own repository environment, but that does not connect it to a browser on your computer. Unless your deployment documents a local bridge and you have verified it, run the browser step locally and hand Aider the minimized report. This keeps the private login in the browser environment and gives the coding agent concrete evidence for a patch.

For the Tabbit side, see the Tabbit CLI guide, connect an agent to an existing browser, reuse a signed-in session, and Codex CLI setup example. Related decision guides cover the first browser-agent task, browser MCP versus CLI, browser session basics, and local web-app validation. They explain the browser side, not native Aider integration.

A practical workflow: browser report, then Aider patch

Tabbit Browser fits when a human-facing page needs inspection in the same signed-in environment used for review. A local browser task can stay in its own task tab while you keep the code editor and other research tabs open. Once the task saves a report, Aider can read that file and work on the repository without trying to infer what the browser showed.

The handoff is deliberately explicit. /web is for importing page text. /run runs a command the user or local setup has authorized. If the installed Aider client cannot call the Tabbit launcher or load its skill, the user should run the browser task themselves or use a local agent with verified skill support.

Decide which tool should own each step

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.