Install
There are two real ways people end up using this project:
- install the published package in Pi
- work from the repo locally during development
The important thing is not to mix those up without meaning to, because Pi can end up loading a different copy than the one you think you are testing.
Requirements
Update Pi to 0.74 or newer before installing this package. Pi packages moved to the @earendil-works/* scope in that version. On older Pi, stay on @demigodmode/pi-web-agent@0.6.x. The extension works on Pi 0.99 and 1.0.
CI runs on Node 22. The locked runtime dependency undici@8.10.2 declares Node >=22.19.0; that is its dependency requirement, while this repo's CI covers the Node 22 line.
Install from npm in Pi
pi install npm:@demigodmode/pi-web-agentThat installs the published package.
For the published package, Pi loads the compiled runtime from dist/extension.js through the pi.extensions entry in package.json.
After install/reload, run:
/web-agent doctorThat checks whether the package loaded and reports the configured search, fetch, and headless backends.
Browser rendering
Headless rendering first tries a local Chromium-family browser. Supported local browsers are Chrome, Chromium, Edge, and Brave when they can be detected on Windows, macOS, or Linux.
If none is detected, web_explore tries Playwright-managed Chromium with headless: true. That browser must already be installed; installing pi-web-agent does not download it. Firefox/Safari-only systems can still use search and plain HTTP reads.
To install the matching Chromium build, run the installed package's Playwright CLI as the same user who runs Pi. Start in the @demigodmode/pi-web-agent package directory. For Pi's default global npm installation:
cd ~/.pi/agent/npm/node_modules/@demigodmode/pi-web-agent
node -e "const path = require('node:path'); require('node:child_process').execFileSync(process.execPath, [path.join(path.dirname(require.resolve('playwright/package.json')), 'cli.js'), 'install', 'chromium'], { stdio: 'inherit' });"Adjust the directory for a project or custom installation. This resolves the Playwright dependency from that package directory, including a nested copy, so the browser matches the version Pi will load. If a package update changes Playwright, rerun the command. Linux also needs the browser's system libraries; see Playwright's browser installation and system requirements.
Doctor detects local browsers. Its managed Chromium fallback configured line describes the fallback configuration; it does not check that the managed browser exists or can launch.
Work from the repo locally
This repo also includes a project-local Pi extension entrypoint at .pi/extensions/pi-web-agent.ts.
That path is for local development and reloads while you are working in this repo.
Config files after install
The package stores presentation and backend settings in real JSON files.
Global config:
~/.pi/agent/extensions/pi-web-agent/config.jsonProject config:
.pi/extensions/pi-web-agent/config.jsonProject config overrides global config.
If you change settings through /web-agent, those files are what get updated.
Backend config
The default backend setup is:
{
"backends": {
"search": { "provider": "duckduckgo" },
"fetch": { "provider": "http" },
"headless": { "provider": "local-browser" }
}
}For a self-hosted or hosted-backend setup, open:
/web-agent settingsChoose Backends to set:
- search provider:
duckduckgo,searxng,brave,youcom,exa,tavily, orgoogle-serp - SearXNG URL, for example
http://localhost:8080 - Google SERP endpoint URL, for example
https://google.serper.dev/search - fetch provider:
httporfirecrawl - Firecrawl URL, for example
http://localhost:3002 - optional fallback behavior
The hosted search backends don't need a baseUrl (except google-serp, which needs the endpoint of the vendor you use); each reads a key from the environment, then you pick the provider in /web-agent settings. They're discovery-only, so web_explore still reads pages, ranks sources, and writes caveats itself.
If your Firecrawl instance requires a key, prefer an environment variable:
PI_WEB_AGENT_FIRECRAWL_API_KEY=...The settings UI does not write API keys. For local-only configs you can still add "apiKey": "..." to the fetch config manually. Saving Backends replaces that scope's backend section without the Firecrawl apiKey or proxy password, even if you edited another field. Use environment variables to keep those secrets through settings saves.
Run /web-agent doctor after changing backend config. It validates required baseUrl values, warns when a hosted search provider is selected without its key, checks hosted backends when a key is present, checks configured SearXNG/Firecrawl endpoints with a short timeout, and shows the network allow list and whether the upstream proxy is trusted to resolve names.
Backend config also supports explicit fallback and a small set of provider options. See Backends for the full shape, including all the hosted search providers.
Environment variables
Secrets live in the environment, not in config the settings UI writes. The ones the package reads:
PI_WEB_AGENT_BRAVE_API_KEY: Brave searchYDC_API_KEY: You.com searchEXA_API_KEY: Exa searchTAVILY_API_KEY: Tavily searchPI_WEB_AGENT_GOOGLE_SERP_API_KEY: Google SERP endpoint search (baseUrl+ header key, any vendor)PI_WEB_AGENT_FIRECRAWL_API_KEY: Firecrawl fetchGITHUB_TOKEN: optional for public GitHub content; private GitHub reader and repo-research access needGITHUB_TOKENorgh auth login
This package integrates with existing self-hosted services. SearXNG/Firecrawl installation, Docker Compose files, reverse proxies, TLS, and auth setup belong to those projects' docs.
Repo research needs git
Pasting a GitHub repo link makes web_explore clone that repo, so git 2.32 or newer has to be on your PATH. That's true on Windows, macOS, and Linux. Nothing else in the package needs git. /web-agent doctor has a repo research: line that shows your git version and where the GitHub token comes from.
Pi versions
The extension works on Pi 0.99 and 1.0. typebox is a peer dependency that Pi already provides to extensions, so if you installed an older version of this package, update or reinstall it so the old bundled copy goes away.
Watch out for mixed setups
If you have both the npm-installed package and the local repo-based extension in play, it gets easy to think you are testing one copy when Pi is actually loading the other.
We already ran into exactly that during development.
If behavior looks stale, missing, or just weird, check what Pi actually loaded before you debug anything else.
How to sanity-check what Pi loaded
A few practical checks help:
- make a small visible local change and use
/reload - restart Pi after install changes
- check whether the behavior matches the local repo or the published package version
- if needed, temporarily remove one install path so there is only one source of truth
It is a boring problem, but it is the kind that wastes a lot of time if you miss it.