Gripi is a desktop and web portal for Pi, powered by a self-hosted gateway. Run the gateway on a development machine or home server with Pi CLI installed, then use Pi from the desktop app or any web browser. Locally, or over an encrypted private network.
Pi stays Pi. Gripi does not alter Pi’s system prompt, patch Pi, install extensions, rewrite sessions, or change Pi-owned configuration. It is a gateway and UI layer for accessing the Pi environment you already run.
Try the live interactive demo →
No installation required. Responses and backend actions are simulated.
The project is a fully vibe-coded alpha version ATM. Initially, it was supposed to be a quick proof of concept, but I ended up using it for my daily work and I actually like it. So please, feel free to try it; but expect some rough edges, missing features, and behavior that may change. Happy to look at any feedback (use Github issues)!
The gateway installer requires curl and Git. Running Gripi also requires Pi CLI available on PATH, working, authenticated, and configured under the same OS user as the gateway.
bash -o pipefail -c 'curl -fsSL https://raw.githubusercontent.com/melounvitek/gripi/master/bin/install | bash -s -- gateway'What it does
- Downloads and runs Gripi’s current installer from the
masterbranch. - Checks that Git is available.
- Installs Mise to
~/.local/bin/misefrom its official installer ifmiseis not already available. - Clones Gripi into a temporary directory.
- Uses Mise to install Gripi’s pinned Go and Node.js versions.
- Installs Node dependencies, builds the Go gateway, and ensures an admin password exists in
~/.config/gripi/env. A newly generated password is printed. - Moves the completed checkout to
~/.local/share/gripi. It refuses to overwrite an existing installation.
It does not install or configure Pi, and it does not start the gateway.
Start the gateway:
~/.local/share/gripi/bin/startBy default, the gateway listens only on 127.0.0.1. Open http://localhost:4567 and use the admin password in ~/.config/gripi/env to approve your browser.
The desktop app installer is independent of the gateway. It requires curl and Git and supports macOS and Linux. On Linux, FUSE 2 is also required (fuse2 on Arch Linux).
bash -o pipefail -c 'curl -fsSL https://raw.githubusercontent.com/melounvitek/gripi/master/bin/install | bash -s -- desktop'What it does
- Downloads and runs Gripi’s current installer from the
masterbranch. - Checks that Git is available.
- Installs Mise to
~/.local/bin/misefrom its official installer ifmiseis not already available. - Clones Gripi into a temporary directory.
- Uses Mise to install the pinned Node.js version and build the Electron desktop app.
- Installs or replaces
Gripi.appunder~/Applicationson macOS, or installs and registers the AppImage under the user’s XDG data directories on Linux. - Removes the temporary checkout. It does not install the gateway.
The desktop app connects to a running gateway and can store and switch between multiple gateways.
There is no mobile app, but on iPhone, adding the gateway to the Home Screen with Apple's Open as Web App flow works nicely. On iOS/iPadOS 16.4 or newer, the installed web app can enable Web Push notifications for completed replies; they continue working while Gripi is closed and require no App Store installation or Apple developer account. The gateway must be reached over HTTPS and have outbound internet access to the browser's push service.
By default, the gateway runs in single-user mode and shows all Pi sessions to one trusted user. Optional multi-user mode gives each user a private user token and shows only the sessions associated with that token.
Multi-user mode is intended for trusted users. It does not provide OS-level process, filesystem, or credential isolation, and settings such as the selected model and thinking effort are currently shared between users. See configuration to enable it.
Do not expose the gateway directly to the public internet. Anyone who can use it can start Pi processes with the gateway machine's filesystem and credentials. Every approved user can directly execute arbitrary shell commands as the gateway OS user, with that user's filesystem, credentials, environment, and network access. In multi-user mode, session visibility is separate, but all approved users share this same OS-level authority.
Keep access approval enabled for any gateway reachable from another device: browser approval in single-user mode, or user-token approval in multi-user mode. Use HTTPS or an encrypted VPN such as Tailscale for remote access; ordinary LAN or Wi-Fi HTTP can expose passwords and access cookies. Production mode rejects remote plaintext HTTP unless GRIPI_ALLOW_INSECURE_REMOTE_HTTP=1 explicitly allows transport already encrypted by a private VPN. Only disable approval when access is already limited to trusted devices and users. Multi-user mode separates session visibility for trusted users; it is not a sandbox and does not isolate filesystem, process, or credential access.
Gripi is intentionally thin around Pi. It uses Pi’s existing runtime, sessions, tools, models, and configuration instead of replacing them with Gripi-specific behavior. Gateway-only metadata is stored separately when needed.
By default, Gripi automatically approves project-local resources for each Pi process it starts. This ensures project settings, extensions, skills, prompts, themes, system prompts, and packages work without first opening the directory in Pi CLI. Unlike Pi CLI’s default trust workflow, merely opening a project in Gripi may therefore load extensions or package installation scripts that execute arbitrary code as the gateway OS user. Only open projects whose contents you trust. See configuration to disable automatic approval.
The composer supports Pi-style @ file search and path completion. !command runs a shell command and includes its result in later model context; !!command runs it but excludes its result from model context. Shell output appears when the RPC command completes rather than streaming. Bash remains available while Pi is running. When both are active, Stop cancels the shell command first; press Stop again to cancel the agent run. In a brand-new unsaved Pi session, bash history remains process-resident until Pi persists the session with an assistant response; Gripi does not write Pi session files itself.
While Pi is running, the send button steers by default; use its menu to select Follow-up mode for the next message. On desktop, Enter steers by default, Alt+Enter queues a follow-up, and Shift+Enter inserts a newline. Slash commands follow Pi CLI behavior: prompt templates and skills are queued using the selected delivery mode, extension commands run immediately, and built-in commands entered in Steer mode run as controls rather than messages.
Gripi supports RPC-compatible extension UI such as select, confirm, input, editor, notify, status, title, and editor-prefill requests. /reload refreshes the current Pi process’s extensions, skills, prompts, themes, and context files, then refreshes Gripi’s slash-command catalog. Pi terminal keybindings are not reloaded because the web interface uses Gripi’s browser controls. If a workflow depends on Pi’s native terminal UI, custom TUI components, terminal keybindings, or ctx.mode === "tui", use Pi CLI directly.
Use the tag icon in the conversation header or Tags… in a session’s menu to group related sessions across projects. Click a tag to filter the sidebar; the adjacent × clears that tag filter. Pinned sessions remain visible. Tags are saved separately from Pi session files and are private to each user in multi-user mode.
Forks and clones inherit tags. The new-session dialog prefills the active filter’s tag, which you can remove before starting. Tag names are normalized to lowercase; unused tags disappear from suggestions.
If you do not already have a session-naming workflow, consider installing @furbyhaxx/pi-session-naming:
pi install npm:@furbyhaxx/pi-session-namingThe gateway is implemented in Go. The browser UI and demo use native JavaScript without a frontend build step, and the desktop shell uses Electron. Project setup and the canonical test suite require Pi CLI on PATH; mise run setup does not install Pi.
mise run dev
mise run test
mise run frontend-check
mise run pi-extension-check
mise run desktop-check
mise run fake-pi-check
mise run e2eSee testing for the complete check matrix, managed browser suite, external implementation contract, and optional real-Pi smoke test.