Parchi: a chat-driven browser copilot that runs as a Chrome or Firefox extension

What problem Parchi solves, and for whom

Most browser automation is written, not spoken. You script a selector, it breaks when the page changes, and you fix the selector. Parchi takes the other position: the README describes it as a "chat-driven browser automation in a side panel" that can navigate, read, click, type, extract and summarize. The unit of work is a prompt, and the browser tools are the executor.

The intended user is someone who already pays for an LLM API key or runs a local model and wants it to touch the browser. The repository is a TypeScript monorepo with three workspaces: packages/extension for the runtime, UI and tools, packages/backend for a Convex backend handling auth, billing and proxying, and packages/shared for schemas, prompts and runtime types. That layout tells you the extension is the product and the backend is optional plumbing around it.

It is not a no-code scraping product. There is no published store listing described, no hosted signup flow documented, and the install path starts with git clone. The audience is engineers and technically comfortable power users who will read a safety notice and still decide the trade is worth it.

How the side panel, tools and orchestrator fit together

The README lists the core features as streaming chat plus a tool execution timeline, a set of browser tools (navigate, read, interact, tabs, screenshots), profile-based model and provider configuration, an orchestrator with a subagent flow, session history and exports, and tool permissions with a domain allowlist.

Read that list as an architecture. A prompt enters the side panel, streams to the configured provider, and the model responds with tool calls rather than prose. Those calls are shown on a timeline, which matters because it means the user sees what the agent intends before or while it happens rather than after. The orchestrator plus subagent flow suggests one model instance plans and delegates while others execute narrower steps, though the README does not spell out the message passing between them.

Configuration is profile-based, so provider, endpoint, model ID and optional custom headers can be switched as a set. That is the model-agnostic claim made concrete: the same extension can talk to OpenAI, an Anthropic-compatible endpoint, OpenRouter, or a local server on http://localhost:11434/v1. The domain allowlist and tool permissions are the containment layer, and they are the part worth auditing first, because a browser agent with click and type access is only as safe as its narrowest restriction.

Installing Parchi and getting a first model response

The README gives a Chrome path as the recommended one. Clone the repository, install workspace dependencies, and run the build script. The build writes to dist/, which is the directory you load as an unpacked extension.

git clone https://github.com/0xSero/parchi.git
cd parchi
npm install
npm run build

After that, open chrome://extensions, enable Developer mode, click Load unpacked, and select dist/. The extension should appear in the toolbar and open its side panel.

Firefox uses a separate build target and a different load path. The README says to load the generated extension from dist-firefox/ through about:debugging.

npm run build:firefox

With the extension loaded, open settings and configure an OpenAI-compatible provider. The README lists OpenAI at https://api.openai.com/v1, OpenRouter at https://openrouter.ai/api/v1, and a local option at http://localhost:11434/v1 for Ollama or LM Studio. You set an API key, a base URL, a model ID, and optionally custom headers. Then ask the side panel to navigate somewhere and read the page, and watch the tool timeline to confirm the calls it makes are the ones you expected.

If you change sidepanel UI code, the README is explicit that you rebuild and reload the extension from dist/.

The safety notice is the most honest part of the README

Parchi's README opens with a warning block rather than burying risk in a footer. It states that automation may violate site terms of service, that prompt injection can cause unsafe actions, and that sensitive information can be exposed if you run untrusted prompts or pages. It closes by telling you to review model output and keep strict tool and domain controls enabled.

That is a real limitation, not a disclaimer to skim. A browser agent that can read the current page and then act on it has a direct path from untrusted page content to tool calls. A page can contain text aimed at the model, and if the model treats that text as instruction, the domain allowlist is the only thing standing between the injected prompt and your session. The README does not describe an injection detector or a confirmation step for destructive actions, so the mitigation it names is user review plus configuration discipline.

The practical consequence: Parchi is the wrong tool for unattended automation on pages you do not control, and it is the wrong tool if you cannot commit to reading the tool timeline. It is also a poor fit if your organization forbids extensions loaded outside a managed store, since the documented install is an unpacked build.

Where Parchi sits next to scripted automation

The obvious alternative is a scripting framework such as Playwright or Puppeteer. The difference is not quality, it is who decides the next step. In Playwright you write the sequence in advance: selectors, waits, assertions, all fixed at authoring time. The script is deterministic and reviewable line by line, and it fails loudly when the DOM changes.

Parchi inverts that. The sequence is decided at runtime by a model reading the page, which handles layout drift and one-off tasks that are not worth scripting. The cost is that the execution path is not fixed in advance, which is exactly why the README pushes you toward the tool timeline and the domain allowlist. A second alternative is a hosted browser-agent service, but those generally route your page content through someone else's infrastructure. Parchi's local endpoint option at http://localhost:11434/v1 is the concrete difference: with a local model, the page content does not have to leave the machine, though the extension itself still needs the provider you configure.

Choose scripted automation when the task repeats and correctness matters more than flexibility. Choose Parchi when the task is exploratory and you are present to watch it.

Maintenance, build cost and the MIT licence

The repository is not archived, and the last push was on 2026-09-03. The most recent tagged release is v0.6.0 from 2026-03-23, titled "UI Polish & Settings Cleanup", with v0.5.1 and v0.5.0 before it in March 2026. The package.json version is 0.6.5, which is ahead of the newest tag, so the tags are not tracking every commit. There is a verify:version-sync script in package.json, which suggests the project cares about that drift even if the tags lag.

The upgrade cost is the build. Parchi is not distributed as a signed store package, so every update means pulling, rebuilding, and reloading the unpacked extension. The script list is long and includes typecheck, lint, unit, integration, e2e, orchestrator, API and performance harnesses, plus check:repo-standards and check:tech-debt. You do not have to run all of them, but a project that ships that many checks expects contributors to run some.

The licence is MIT, which is permissive and places few obligations on reuse. That is a statement about the licence text, not advice about your situation; if you plan to redistribute a modified build, read the LICENSE file and PRIVACY.md in the repository root yourself.

Editorial conclusion

Adopt Parchi if you want chat-driven browser automation that stays in the side panel and can be pointed at a local OpenAI-compatible endpoint, and you are willing to build it from source and review model output before it acts. Do not adopt it if you need a signed extension from a store, a documented rollback story, or unattended automation on pages you do not control. Before anything else, run npm run build and load dist/ unpacked, then check whether the domain allowlist and tool permissions in settings are granular enough for the sites you actually work on.

Frequently asked questions

Official sources

1. 0xSero/parchi on GitHub
2. License: MIT
3. Project website
4. README
5. Releases