EXP-0007 — Pinokio: a one-click launcher for AI tooling that forge could install but not run

23 June 2026#forge#electron#desktop#ai-tooling#stable-diffusion#open-source#MIT#launcher#security-model

Most of the genuinely interesting AI tools right now are free, open-source software you have to install yourself. Stable Diffusion, the various local large language models, Whisper for transcription, ComfyUI for image pipelines — none of them are an app you can just download from the App Store. They are projects on GitHub that require some combination of: cloning a repository, creating a Python virtual environment, installing dependencies, downloading multi-gigabyte model files, configuring a config file, running a server, opening a browser to localhost. Doing this once is a moderately frustrating evening. Doing it for three different tools is most of a weekend.

Pinokio is a single desktop application that turns that whole process into a button. A developer wraps their AI tool into a "pin" (a small install script that lives in a public Git repository); a user downloads Pinokio once, browses the "Discover" page inside the app, and clicks "Install" on whatever they want to try. Pinokio runs the install script, manages the files in an isolated folder (~/pinokio/), and gives the user a "Launch" button when it's done. Most people who use Pinokio use it specifically for AI tools — Stable Diffusion is by far the most common use case.

Forge is our experiment harness — when a project is marked for evaluation, forge clones it and tries to build and run it in a clean sandbox so we can write up what we actually found.

For Pinokio, forge ran into the right kind of wall: Pinokio is a desktop GUI application. It runs on Windows, macOS, or Linux laptops where there's a screen. Forge's sandbox is a headless container with no screen. So forge could verify that Pinokio's source code is clean (MIT-licensed, ~2 MB), that its 863 dependencies install successfully (60 seconds), and that the project's security model — which is the most interesting design choice — is unusually well-thought-through. But forge could not actually click around in the app.

The interesting finding is the security model, which we describe below. The actual "does the GUI feel good" question is one a human can answer in five minutes on their own laptop, and we recommend that as the next experiment.

Status: experimented, result partial. Dependencies install cleanly (863 packages, 60 s). The bench stops there: Pinokio is an Electron desktop application whose entire value is the GUI, and forge's sandbox has no display server.

This is a forge writeup of pinokiocomputer/pinokio at commit 4ee726c (v7.2.6). It is a desktop launcher, written by @cocktailpeanut, that ships as a one-click installer + GUI for any open-source AI project that has been packaged as a "pin" (a Node.js install/run script in a public Git repo). MIT-style license. ~2.1 MB cloned.

TL;DR

What it is. An Electron desktop app whose "Discover" page lists curated open-source AI projects — Stable Diffusion, Whisper, LLM front-ends, etc. — that have been packaged as Pinokio scripts. One click installs the project to ~/pinokio/<name>; another click runs it. Each project gets an isolated environment.
Install: clean. 863 npm packages, 60 s with --ignore-scripts to skip the Electron post-install rebuild. License is MIT-template (titled Copyright 2023 Pinokio instead of MIT License).
Run: deferred. Pinokio's entry point is electron .. Headless Electron in a sandbox requires xvfb-run (an X virtual framebuffer) plus --no-sandbox plus disabled hardware acceleration. Forge's sandbox is offline-by-default with no X server. The headless bench is doable but cost > value for an experiment whose user-facing surface is purely visual.
Security model is the interesting finding. Pinokio's README spells out a careful threat model — scripts isolated to ~/pinokio, third-party scripts must come from public Git, verified-publisher process, repo transfer-and-freeze for the "Discover" feature — that is more rigorous than most launchers in this space. This is the substantive content of the writeup.

What it is

Pinokio is a UI on top of "I have a fresh laptop and I want to try running this AI project today." That problem is real. Most open-source AI tools — Stable Diffusion WebUI, Whisper, ComfyUI, the latest TTS or VTT model, the latest local LLM front-end — ship as Python or Node projects with non-trivial setup: clone, create venv or conda environment, install dependencies, download model weights (often multi-GB), configure a config file, run a server, open a browser. Each project does this slightly differently. None of them does it the way the next project will. A normal user wanting to try three AI tools in one weekend will spend most of the weekend fighting environments.

Pinokio's pitch is: the project ships a pinokio.json (or .js) "script" in its repo describing exactly those install + run steps. The Pinokio desktop app reads that script, runs it inside ~/pinokio/api/<project>, manages the lifecycle (start, stop, update, uninstall), and surfaces the result — a local URL, a CLI prompt, a popup window — in a unified GUI. The user clicks "Install," waits, clicks "Launch."

The architecture, in three pieces:

The Electron shell (this repo). main.js, preload.js, popup-toolbar.html, splash.html, update-banner.html, prompt.html. About 20 JS/HTML files at the top level. Very small.
The kernel (Pinokiod, in a separate npm package). The actual install/run engine. Imported as const Pinokiod = require("pinokiod") in main.js.
The "pins" — scripts in third-party repos. Pinokio runs them; they live elsewhere.

This means the bench-evaluable surface in this repo is the Electron wrapper, which is mostly window management, system-tray behavior, and platform-specific tweaks (Linux Ozone hints, Wayland/X11 detection, GPU disable). The real engine is in another package; the real value is in the curated "Discover" page.

The security model worth quoting

Most launchers in this space (Anaconda, Docker Desktop, various AI "one-click installers") get hand-wavy about what happens when you run a third-party script. Pinokio's README does not. The model has five enforceable claims:

All scripts run from public Git repositories. No closed-source pins.
Scripts and their installed binaries are isolated to ~/pinokio. Everything written by a pin lives under ~/pinokio/api/<project>; all binaries installed by Pinokio's built-in package managers live under ~/pinokio/bin. A pin that deviates is, per the README, the "risk factor."
Featured "Discover" scripts must be verified. The maintainer (@cocktailpeanut) personally vets each publisher before they can submit a pin for the Discover page.
Repo transfer-and-freeze. To be featured, the publisher must transfer the script repo to the official pinokio-factory GitHub organization, where the admin retains rights to modify it if a vulnerability is later discovered.
Delist + patch authority. If a featured pin behaves badly, the admin can both delist it and push a fix because the repo is under the org.

Whether this works in practice depends on how scrupulously the admin enforces it. But the model is more rigorous than most. A typical "marketplace" pattern — Chrome Web Store, NPM, Hugging Face — leaves moderation reactive: the bad code ships first, and is taken down later. Pinokio's transfer-and-freeze flips that: the bad code can't ship featured at all without sitting in an org the admin controls. That's a real design choice.

The trade-off is centralization. Pinokio is one maintainer with admin rights to every featured pin. If that maintainer disappears, the featured catalog has no successor. The README doesn't address governance handover. For a small project run by a passionate single maintainer, this is fine — but it's worth knowing.

What forge actually verified

Two things:

Clonable + MIT-compatible. Public repo, 2.1 MB shallow clone, LICENSE file is the MIT template with a non-standard title line. For forge's purposes (clone, build, redistribute the report) that's adequate.
npm install --ignore-scripts succeeds. 863 npm packages, 60 seconds wall, exit 0. The --ignore-scripts is necessary because the upstream postinstall2 script runs monkeypatch (which copies patched files into node_modules/app-builder-lib and node_modules/@electron/rebuild) and then electron-builder install-app-deps, both of which are build-stage operations that assume a host environment, not a sandboxed CI container. Skipping them produces an installable but not-yet-bundleable tree.

What forge did not verify: actually launching the app. npm start runs electron ., which in turn loads main.js, instantiates Pinokiod, and opens the window. In a no-display sandbox, Electron exits with error: Failed to connect to the bus. Running it under xvfb-run is possible but produces no human-readable output anyway (the value of the app is the visible UI). The right forge bench for this product would be a manual session on a real laptop with screenshots — which is a perfectly valid future experiment, just not one this sandbox is built for.

What we'd actually verify next

Three reasonable follow-ups:

Pin a specific Discover script and run its install steps directly (without the Electron shell) inside a forge sandbox. If a pin says "clone repo X, create venv, pip install Y, run server," forge can do all of those things headlessly and assert on the exit codes and the listener that comes up. This is a useful surface-level test of Pinokio's "the script is the contract" promise.
Audit a popular featured script — pick the top three Discover items by stars and read what they actually install. The README claims scripts are auditable; forge can confirm by walking the install graph and listing every binary and every URL fetched.
Side-by-side launch with xvfb-run + screenshot, on a Linux host with a display. This would be a "verify-via-screenshot" experiment, a different category than forge usually runs but reasonable for visual tools.

Comparables

Project	Posture
`oobabooga/text-generation-webui`	One specific AI app, ships its own installer. A common Pinokio pin.
`AUTOMATIC1111/stable-diffusion-webui`	Same shape: huge installer scripts, common Pinokio pin.
Docker Desktop	Generic container manager. Different abstraction (containers, not pins).
Anaconda Navigator	Closest historical analogue — desktop GUI for Python environments. Heavier, slower-moving, not AI-specific.
Hugging Face Spaces (hosted)	Same problem solved differently — run someone else's app in their cloud, no local install.

Pinokio sits in a real gap: lighter than Docker, AI-aware where Anaconda isn't, local where Hugging Face Spaces isn't. The market for "I want to run the latest AI thing on my own GPU without spending two hours" is large and underserved.

Reproducibility


upstream repo	https://github.com/pinokiocomputer/pinokio
commit pinned	`4ee726ccc3877d7bfbece2bddb61ae6635700b7c` (v7.2.6)
license	MIT-template (titled `Copyright 2023 Pinokio`)
base image	`node:22`
image digest	`sha256:e0d149b4727ac0c20d9774e801e423d7a946a0bffced886f42cfe9cd3c67820a`
install	`npm install --ignore-scripts --no-audit --no-fund` — exit 0, 60 s, 863 packages
smoke probe	deferred — Electron + GUI requires `xvfb-run` or a host display; out of scope for headless sandbox

Companion gist contains the install log, the env manifest, and the LICENSE.