pikibun 0.20.0 → 0.22.0

package/README.md

@@ -66,7 +66,7 @@ Each exact command and timeout needs the approval of the **host owner**, or of a
 
 ## macOS, Windows and hosts without bubblewrap
 
-The isolated sandbox needs Linux (or WSL2 on Windows). macOS and native Windows can try their own experimental sandboxes with `--experimental-sandbox` (see the main README, "Experimental sandboxes on macOS and Windows"). On macOS, native Windows, or Linux without bubblewrap, you can also opt out of isolation:
+The isolated sandbox needs Linux (or WSL2 on Windows). macOS and native Windows can try their own experimental sandboxes with `--experimental-sandbox` (see "Experimental sandboxes on macOS and Windows" in [`docs/hosts.md`](https://github.com/OpenCara/pikibun/blob/main/docs/hosts.md#experimental-sandboxes-on-macos-and-windows)). On macOS, native Windows, or Linux without bubblewrap, you can also opt out of isolation:
 
 ```sh
 npx pikibun@latest connect --unsafe-no-sandbox
@@ -122,14 +122,23 @@ The sandbox has no network, so `gh` and `curl` inside it can't reach GitHub. Age
 - `github_comment` posts a comment. It waits for a human approval unless the session owner's message chose **Auto-approve**.
 - `github_issue` opens an issue with exactly the approved title and body in one of those repositories, and gives the agent its number and URL (connector newer than 0.9.0). It waits for a human approval unless the session owner's message chose **Auto-approve**. If GitHub refuses (issues turned off, no access), no issue is opened and the agent gets GitHub's reason.
 
-## Web pages and search
+## Extensions
 
-Agents read web pages with `web_fetch` and search the web with `web_search` (connector newer than 0.9.0).
+Sessions on this host run the Pi extensions their workspace chose that are installed here at the same version. The host's owner installs them from Pikibun (the host's page), or here:
 
-- `web_fetch` reads one `https://` page from this host, as far as the workspace's network access lets the session's sandbox reach, and never at an address in this host's own networks. It sends no cookies or credentials and only reads; HTML comes back as text, images as images. It needs no approval, during a shared message. On a host running without the sandbox it still follows the workspace's network access.
-- `web_search` asks Pikibun, which searches with the provider its operator configured, where the workspace turned web search on. The provider's key never reaches this host.
+```sh
+npx pikibun@latest extensions add npm:cc-safety-net@2.7.2         # an exact version
+npx pikibun@latest extensions add git:github.com/acme/ext@<commit>  # a full commit, over https
+npx pikibun@latest extensions add ./my-extension.ts                # a dev extension: your own sessions only
+npx pikibun@latest extensions list                                 # what each offers, ignores, or why it doesn't load
+npx pikibun@latest extensions remove cc-safety-net
+```
+
+They live in the connector's state directory; npm runs none of their install scripts unless you add `--allow-scripts`. A running connector picks up changes made here within half a minute. `pikibun connect --no-remote-installs` refuses installs asked for in Pikibun.
+
+Extensions run in the connector, as this machine's user, with your files, credentials and network, outside the sandbox. Install only code you trust. Their tool calls are approved like host commands. Pikibun's own `web_fetch` and `web_search` tools are retired: web search comes from extensions.
 
-What they return is untrusted input, like any repository content.
+Three extensions are built into the connector, so there is nothing to install: `piki:gh`, `piki:glab` and `piki:azure-cli` give sessions the GitHub, GitLab and Azure CLIs (`gh`, `glab`, `az`) where their workspace uses them. Install those commands on this machine and sign in to them (`gh auth login`, `glab auth login`, `az login` and `az extension add --name azure-devops`); their tool calls act as you. `pikibun extensions list` shows them.
 
 ## Chat options