Date: 2026-09-08
pi-lease is a fairly thin wrapper
around Mario Zechner’s pi-chrome-use extension. It does not contain a new
browser automation engine, and I do not want to pretend that it does.
What it adds is an environment around browser automation: a visible Chromium
window with its own persistent profile, a Pi session configured to use
pi-chrome-use, some instructions about when that browser should be used, and
lifecycle management so the browser belongs to that session and disappears when
the session ends.
The project came out of a much fuzzier idea: I would quite like an assistant that can deal with some of the boring bureaucratic work I do through websites. pi-lease is one small experiment in giving such an assistant hands.
I do not remember a moment when I sat down and decided that what the world
needed was a wrapper around pi-chrome-use.
I was thinking more generally about an assistant. There are administrative tasks I would happily automate if I could do so in a way I understood and was comfortable with. Quite a few of them happen in authenticated web applications and forms.
I also considered broader desktop automation, and may return to it. But much of what I currently need falls into two convenient groups. Command-line work is already something coding models are remarkably comfortable with. The other large group lives in a browser.
That made browser automation an obvious place to experiment.
The planning overlapped with the conversations that eventually produced pi-pew-pew. I would not claim there was a clean sequence in which I built one and then logically derived the other. Search, fetching, rendering, browser control, and the larger assistant idea were mixed together for a while, much of it through brainstorming with AI.
The separation became clearer later.
pi-chrome-use Does the Clever PartThe actual browser-control capability comes from the upstream pi-chrome-use
extension. That is the thing that lets Pi inspect and interact with a Chromium
browser.
pi-lease wraps that capability rather than replacing it.
When I looked back at the code, the wrapper turned out to be a little more
specific than I remembered. It launches a visible Chromium instance with a
dedicated persistent profile, connects the Pi session to that browser, verifies
the browser endpoint it started, loads pi-chrome-use for that session, and
owns the lifecycle of the browser process.
The profile persists, so useful browser state such as logins can persist. The running browser session does not. When the Pi session ends, pi-lease shuts down the browser it owns and cleans up the transient state.
That is quite close to how I wanted the thing to feel: open a particular Pi window, give that session a browser, do the job, and have the whole active setup crash and burn when I close it.
My ordinary Pi sessions remain ordinary Pi sessions.
pi-lease also gives the model instructions about what this browser is for.
The useful part is that those instructions do not say “you have a browser, therefore use it.” They point in almost the opposite direction. Ordinary files, shell tools, and APIs remain preferable when they solve the problem. Browser automation is for cases where the model actually needs an authenticated web UI, visual browser state, or interaction with a page.
I do not want browser automation to become the new hammer for every task merely because I installed it. Giving an assistant hands does not mean asking it to use them to read the newspaper.
The browser is also visible. This is not a security guarantee and pi-lease is not a sandbox. I simply prefer an assistant doing things in a browser I can see to one operating an invisible browser somewhere in the background.
A separate profile also keeps this experiment away from my everyday browser state while still allowing the assistant’s own logins to survive between sessions.
pi-lease does not prevent a model from using a simpler web tool when that is enough.
That distinction now makes sense to me as something like eyes and hands.
pi-pew-pew can fetch a page, render JavaScript when needed, and let a vision-capable model look at the result. It cannot click a button, fill in a form, or operate an authenticated application.
pi-lease is for the latter kind of task. It is also a relatively inefficient way to fetch a page if all I wanted was to read one.
Again, I would not make the history too neat. I did not begin by designing an “eyes module” and a “hands module.” Those boundaries emerged while I was trying to work out what a useful assistant might look like.
I am glad they emerged, though. I can now tell fairly easily which capability I am giving a model and why.
There is not a great deal of original browser-automation code in pi-lease. The project is mostly glue around a good existing tool.
I think that is worth saying plainly. A wrapper can still solve a problem if the problem is not “how do I automate Chromium?” but “how do I make Chromium control fit the way I want to run an assistant?”
For me, that currently means a focused session, a recognisable browser, a separate persistent profile, instructions that discourage unnecessary browser use, and a lifecycle I can terminate by closing the session.
Whether this grows into something more assistant-like is still open. I have ideas about automating boring web-based administrative work, and broader desktop use may come later. I do not yet know which of those ideas deserve to become software.
For now, pi-lease is small enough that I can understand what it adds to
pi-chrome-use.
That is probably the feature I care about most.
Thank you so much for reading!
If you would like to give some feedback please open an issue on this blog’s GitLab.