Paperclip Desktop puts the Paperclip server behind a double click

A launcher, not a fork

Paperclip Desktop is an unofficial Electron wrapper around Paperclip, and the README is unusually clear about what that means. It bundles Paperclip through the official @paperclipai/server npm package inside a native desktop app for macOS, and it ships an unmodified build of the upstream Paperclip server and UI, so what you get in the app is exactly what you would get by cloning and running the main repository. The stated goal is one line, to make running Paperclip as easy as opening an app. The feature list spells out the same thing in five bullets: one click to launch with no terminal, no pnpm install and no Node.js setup, remote connection mode that connects the desktop shell to verified upstream Paperclip remotes in authenticated mode with saved connections and quick reconnects, the unmodified Paperclip bundled inside, automatic updates that pull new desktop releases from GitHub Releases, and native menus, windowing and a system tray. The relationship table is worth reading as a governance note as much as a feature description, since it assigns the Electron shell and installers to this repository and the server, UI and features to the upstream project, with this one maintained by Aron Prins as a community effort and the upstream maintained by the Paperclip team.

Local mode and remote mode take different paths

Under the hood the app does one of two things. It can run the embedded local server flow, or it can verify a remote Paperclip origin through the /api/health and /api/auth/get-session endpoints before loading it in a restricted remote-safe Electron window. That distinction is the security design of the project rather than an implementation detail. A local Paperclip is started by the app and shut down cleanly when you quit, so the server does not outlive the window that owns it. A remote Paperclip is treated as an untrusted origin until it has answered a health check and a session check, and it then runs in a window with an exact-origin navigation policy, which is the standard Electron defence against a remote page navigating the shell somewhere else. The repository layout backs this up. The src/connection/ directory holds connection persistence, remote validation and preflight, and the exact-origin window policy helpers, and src/launcher-html.ts is the internal launcher UI for the chooser, the remote connect flow, the saved connections and the local boot states.

Installing the app, or running Paperclip from source

The install for an end user is a download. The latest installer comes from the Releases page, with a macOS .dmg for both Apple Silicon and Intel, while Windows and Linux are marked as coming soon. You open the app, Paperclip starts automatically, and the dashboard opens in the app window. The README also offers the alternative for anyone who would rather not use a wrapper at all, and the upstream project provides a one command onboarding path.

npx paperclipai onboard --yes

Or you can clone the upstream repository and run it in development mode.

git clone https://github.com/paperclipai/paperclip.git
cd paperclip
pnpm install
pnpm dev

The distinction matters for a specific reason. The wrapper is a packaging convenience, and the upstream repository is where the functionality lives, so anything you need beyond launching the dashboard is a question for the upstream documentation rather than this one. The README is explicit that for everything Paperclip itself can do, orchestrating AI agents, running autonomous companies, governance, budgets, org charts and the rest, the upstream repository is the reference, and that this project does not modify or extend Paperclip's functionality, it only packages it.

The build scripts tell you what the app actually contains

The development requirements are Node.js 20+ and pnpm 9.15+, and the script list is a map of the packaging pipeline.

pnpm install           # Install deps
pnpm dev               # Run Electron in dev mode against the bundled server
pnpm build             # Compile the Electron main/preload TypeScript
pnpm test:connections  # Run connection persistence, preflight, and origin-policy tests
pnpm prepare-server    # Stage the Paperclip server bundle into build/
pnpm build-ui          # Stage the Paperclip UI
pnpm pack              # Build an unpacked app directory (no installer)
pnpm dist              # Build full installers for the current platform

The two stage scripts are the interesting pair, because prepare-server stages the Paperclip server bundle into build/ and build-ui stages the Paperclip UI, and everything the user sees comes from those two artefacts. electron-builder.yml then bundles the @paperclipai/server npm package plus a platform-specific Node.js binary into Resources/app-server/, which is how a Node application ships inside a native app without requiring the user to install Node. The key files section names the rest: src/main.ts is the Electron main process with launcher IPC, local and remote boot orchestration, menu actions and server lifecycle, src/preload.ts is the preload script, and src/updater.ts wires the auto-update against GitHub Releases using electron-updater. The scripts/ directory holds build and release automation, including macOS notarization.

The test names are the security requirements in plain text

The package manifest shows a test suite organised around the risky parts rather than around unit coverage, which is a reasonable choice for a wrapper whose job is to open someone else's web application safely. There is a connections test that runs the connection validation, preflight, connection profiles, window policy, navigation gestures, local server lifecycle and local server health tests, and a release safety test that runs the runtime safety, macOS release asset preparation and esbuild normalization tests. The macOS release asset path has its own test, and the smoke test for the packaged macOS app is a separate script, so a packaged build is checked as a packaged build rather than assumed to behave like the development tree. The release scripts are split by architecture, with local releases for x64 and arm64 and a notarization step for a prebuilt binary. The practical reading is that the two things most likely to break silently, the remote connection checks and the packaged app, are the two things with the most dedicated tests.

The disclaimer is about money and about who is responsible

The disclaimer section is the part of the README a prospective user should read twice, because it defines the risk rather than the feature set. The software is provided as is, without warranty of any kind, express or implied, and the authors accept no liability for the behavior of the bundled Paperclip server, for any agents you configure, or for any outcomes they produce. Then the acknowledgements, and the first is the one that matters most in practice. The app runs AI agents that can execute code, make API calls, and spend money on AI model providers on your behalf, and the user is solely responsible for any costs incurred. The second is that this is an unofficial community distribution, not endorsed by, affiliated with, or supported by the upstream Paperclip team. The third is that it wraps third-party software, so the wrapper authors accept no liability for the bundled server. The last point, cut off in the documentation, is about the user being responsible for reviewing agent actions and setting budgets. The licence is MIT, and the upstream Paperclip licence ships inside the packaged app alongside its source, which is the right thing to do for a wrapper that redistributes someone else's code.

Where Paperclip Desktop is the wrong tool

Three limits. The first is platform coverage, and it is not a small one. Only macOS has an installer today, with Windows and Linux marked as coming soon, so on any other operating system the wrapper does not help you at all and the upstream source route is the only path. The second is that the wrapper adds nothing to the server, and the README says so directly, so if you came looking for a feature Paperclip does not have, you will not find it here, and you will not find it in the upstream repository either. The third is the nature of the trust you are extending. The remote mode exists to point the desktop shell at a Paperclip instance somewhere else, which means the security of that flow rests on the /api/health and /api/auth/get-session checks and on the exact-origin window policy, and a community wrapper is a smaller team than the upstream project, with the disclaimer explicitly disclaiming liability for the bundled server's behaviour. The maintenance picture is otherwise healthy, with v3.2.15 on 2026-10-03, v3.2.14 on 2026-09-21 and v3.2.13 on 2026-09-02, and the last push to the repository on 2026-10-03.

Editorial conclusion

Adopt paperclip-desktop if you want to try Paperclip on macOS without setting up Node.js or a terminal, since it bundles the official server package and handles the server lifecycle for you. Skip it if you are on Windows or Linux, because the README marks those builds as coming soon, and skip it if you need an official distribution, since the project states plainly that it is an independent community distribution that is not endorsed or supported by the upstream team. Before you install, read the disclaimer about agents spending money, because the app runs AI agents that can execute code and call paid APIs on your behalf, and decide whether the local mode or the remote mode matches how you intend to use it.

Frequently asked questions

Official sources

1. aronprins/paperclip-desktop on GitHub
2. Issues
3. License: MIT
4. README
5. Releases