Parchi: a chat-driven browser copilot that runs as a Chrome or Firefox extension
Your AI friend right in your browser
At a glance
- What is it?
- Parchi puts an LLM-driven automation agent in a browser side panel, with tool permissions and a domain allowlist. It is model-agnostic and MIT licensed, but the README is upfront that prompt injection and site terms of service are real risks, and the install path is still a manual unpacked build.
- Who is it for?
- Adopt Parchi if you want browser actions driven from a chat panel and you are willing to configure your own OpenAI-compatible endpoint, including a local Ollama or LM Studio server. Do not adopt it if you need a signed, store-installed extension or a hosted model, because the documented install path is npm run build followed by Load unpacked on dist/, and the README states that automation may violate site terms of service and that prompt injection can cause unsafe actions.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Parchi is for, and who ends up using it
Parchi is a browser extension for Chrome and Firefox that puts a chat panel beside the page and lets the model act on that page: navigate, read, click, type, extract, summarize. The description calls it an AI friend in your browser; the README is more precise, describing a copilot where chat drives browser automation from a side panel. The distinction matters. This is not a summarizer that reads the current tab and stops. It executes tools against the live DOM.
The audience that follows from that is narrow. Someone who wants to say "open the invoice list, find the March one, pull the total" and watch it happen. Someone who already has an API key or a local model server and does not want a vendor account in the middle. Anyone expecting a polished consumer product should read the safety notice first, because the README states plainly 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. That is not boilerplate. It is the honest description of what an agent with click and type permissions is.
The extension, the Convex backend, and the shared package
The repository is a monorepo with three packages and a test tree. packages/extension holds the runtime, the UI and the browser tools. packages/shared holds schemas, prompts and runtime types. packages/backend is a Convex backend that the README labels auth, billing and proxy. scripts/ carries build, release and check scripts; tests/ carries unit, integration, e2e, orchestrator and performance harnesses.
That split tells you where the interesting logic lives. Anything the model can do to a page is in packages/extension, because that is the only package with access to the browser APIs. The shared package is where the tool schemas and prompts are defined, which is why the two other packages can agree on what a tool call looks like. The Convex package is the part worth scrutinising if you plan to run against a local model: the README lists proxy as one of its responsibilities, so a deployment that never touches the hosted service still needs to be checked against whatever endpoint you configure. This is inference from the repository layout, not a claim about runtime behaviour, and the README does not document a request flow diagram.
The feature list names an orchestrator plus subagent flow, streaming chat with a tool execution timeline, profile-based model configuration, session history and exports, and tool permissions with domain allowlist controls. Of those, the tool execution timeline is the one that changes how the thing feels in use: you see which tool ran, in what order, instead of watching a spinner and hoping.
Model configuration is a base URL and a key, nothing more
Parchi does not ship a model. The README instructs you to open the extension settings and configure an OpenAI-compatible provider, then lists four examples: OpenAI at https://api.openai.com/v1, an Anthropic-compatible option, OpenRouter at https://openrouter.ai/api/v1, and a local server at http://localhost:11434/v1, which is the default Ollama port and also where LM Studio can be pointed. Any other OpenAI-compatible endpoint is allowed.
The settings the README names are an API key, an endpoint or base URL, a model ID, and optional custom headers. Profiles sit on top of that, so you can keep more than one provider configured and switch between them. The custom headers field is the escape hatch for gateways that want an organisation ID or a routing header; the README does not enumerate which headers are needed for which provider, so that is on you to look up.
Running against localhost is the configuration that makes the model-agnostic topic label meaningful. It also means the quality of tool calling depends entirely on the model you point at it. The README does not publish a list of models known to drive the browser tools reliably, and it does not describe how a malformed tool call is handled. Treat that as an open question rather than a solved one.
Getting it running: the commands the README gives
The install path for Chrome is four commands and four clicks. Clone the repository, install dependencies, build, then load the result.
git clone https://github.com/0xSero/parchi.git cd parchi npm install npm run build
Then open chrome://extensions, enable Developer mode, click Load unpacked, and select dist/. Firefox takes a different build command, npm run build:firefox, and the generated extension is loaded from dist-firefox/ through about:debugging. The README notes Firefox 109+ in the badge.
For development the README lists npm run typecheck, npm run lint, npm run test:unit, npm run test:integration, npm run test:e2e and npm run check:repo-standards. It also gives one operational instruction that matters more than it looks: if you change sidepanel UI code, rebuild and reload the extension from dist/. There is no hot reload described. Every UI change is a rebuild plus a manual reload in the extensions page, and that cost accumulates over a working day.
Note what is absent. There is no published extension store listing in the material, no npm package to install, and no Docker or single-binary path. Distribution is source plus a local build.
The safety notice is the most important part of the README
Most projects bury the risk paragraph. Parchi leads with it, and the three bullets are specific: automation may violate site terms of service, prompt injection can cause unsafe actions, and sensitive information can be exposed if you run untrusted prompts or pages. The README's advice is to review model output and keep strict tool and domain controls enabled when needed.
The mechanism behind the second bullet is worth spelling out even though the README does not. An agent that reads page content and then decides what to click is consuming text an attacker can write. A page containing instructions addressed to the model is indistinguishable, at the parsing layer, from instructions from the user. The domain allowlist and tool permissions are the mitigation the project offers, and they are the right shape of mitigation, but the README does not describe their defaults. Whether the allowlist starts empty or open, and whether a permission prompt appears before the first click on a new domain, is exactly the thing to check in the settings panel before pointing this at a logged-in account.
The third bullet is the one people skip. If the model endpoint is a hosted provider, page content read by the tools leaves your machine. If it is localhost, it does not. That single configuration choice changes the exposure profile more than any other setting in the extension.
Where Parchi is the wrong tool
Three cases. First, unattended automation. Parchi is a side panel with a human in the loop; the README frames it as chat-driven, and the safety notice asks you to review model output. If you need a scheduled job that logs in at 3am and files a report, a headless framework such as Playwright or Puppeteer with a scripted flow is the correct instrument. Those give you deterministic replay, a CI story, and no model in the decision path. Parchi gives you a conversation and a model that may choose a different click tomorrow. The difference is not quality, it is that one is reproducible and the other is not.
Second, anything where a wrong click is expensive. The README's own warning about prompt injection covers this, but the practical version is that a tool with type and click permissions in a session that is already authenticated can do whatever you can do. If the account behind the tab has payment methods or admin rights, the blast radius is your account, not a sandbox.
Third, environments that forbid unpacked extensions. The documented install is Load unpacked from dist/. Managed corporate Chrome profiles commonly block developer mode. If that describes your machine, the build path described here will not work, and the material does not describe an alternative distribution channel.
Maintenance cost and the MIT licence
Maintenance here has two distinct parts. The extension side is ordinary TypeScript work: npm run typecheck and npm run lint are the fast checks, and tests/ is split into unit, integration, e2e, orchestrator and performance harnesses, which suggests the project expects the orchestrator path to break in ways unit tests miss. The e2e and performance harnesses are the ones that will need attention when browser APIs shift, because extension code is coupled to a moving target on both Chrome and Firefox.
The other part is the model layer. Because Parchi is provider-agnostic, a model deprecation or a change to how a provider formats tool calls lands on you, not on the project. The README's optional custom headers field exists partly for that reason. Budget for the possibility that a provider update degrades tool calling before the project ships a fix.
On licensing: the repository is MIT, and the README links a LICENSE file at the root. MIT is permissive, so redistribution and modification are broadly allowed provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice. Two things the material does not settle: whether the Convex backend package carries the same terms as the extension, and whether any bundled dependency has a different licence. Check LICENSE and the dependency tree yourself before shipping a fork.
What the release history says about maturity
The most recent release listed is v0.6.0, dated March 2026 and titled UI Polish and Settings Cleanup. Before it, v0.5.1 in mid-March and v0.5.0 a few days earlier. The last push to the default branch is September 2026, so the repository is active. The version number is the useful signal: 0.6.x with a recent release focused on settings cleanup means the configuration surface is still moving. If you build tooling or documentation around the settings schema, expect it to shift under you.
The archived flag is false and the default branch is master. The homepage listed is parch i.ai, and the repository description is the same one-liner as the README subtitle. Nothing in the material describes a stable plugin API, a compatibility policy, or long-term support windows, so treat the extension API as internal and unversioned. Pin to a commit rather than tracking master if you depend on it.
Editorial conclusion
Adopt Parchi if you want browser actions driven from a chat panel and you are willing to configure your own OpenAI-compatible endpoint, including a local Ollama or LM Studio server. Do not adopt it if you need a signed, store-installed extension or a hosted model, because the documented install path is npm run build followed by Load unpacked on dist/, and the README states that automation may violate site terms of service and that prompt injection can cause unsafe actions. Before trusting it with logged-in sessions, verify three things: that the domain allowlist and tool permissions are enforced where you expect, that the bundled packages/backend Convex service is not on the request path when you point it at a local endpoint, and that the MIT licence in LICENSE covers the parts you intend to ship.
Community notes