mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-06 10:48:12 +02:00
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The CLI can install and start Paperclip as a managed user service during onboarding. > - Recent fixes now install the service shim and remove the redundant foreground start prompt. > - The service path still ends without a dashboard URL or an open browser. > - The server can also move to a free port when the configured port is busy. > - This pull request adds a health-aware handoff to the managed service's actual endpoint. > - The benefit is that new users can reach Paperclip without starting a second process. ## Linked Issues or Issue Description **What happened?** After interactive onboarding installs and starts the managed service, the command ends without printing the dashboard URL or opening the browser. If the configured port is busy, the service can use a fallback port that the onboarding process does not know. **Expected behavior** Onboarding must print the dashboard URL that belongs to the managed service. An interactive terminal should open the URL after the local health check succeeds. A non-interactive terminal should only print the URL. **Steps to reproduce** 1. Start from a host without an installed Paperclip service. 2. Run another process on the configured Paperclip port. 3. Run `npx paperclipai@<version> onboard` in an interactive terminal. 4. Accept the managed service installation. 5. Observe that the service starts on a fallback port, but onboarding does not provide or open that dashboard URL. **Paperclip version or commit** `b6854e61c` on `master`, after #12148, #12151, and #12153. **Deployment mode** Local managed user service on macOS or Linux. **Installation method** `npx paperclipai@<version> onboard`. The same onboarding path can also run after `install.sh`. Related public pull requests: #12148, #12151, and #12153. ## What Changed - Record each running CLI server's PID, selected port, and dashboard URL in atomic per-instance runtime metadata. - Accept runtime metadata only when its PID matches the active managed service. - Wait for the selected runtime endpoint to report healthy before printing its URL. - Open the URL in interactive terminals and keep headless runs browser-free. - Keep the printed configured URL as a fallback when runtime discovery fails. - Use browser-launch wording that only claims the URL was sent to the opener. - Add runtime metadata, fallback-port, health handoff, headless, and failure-path tests. - Document the managed service dashboard handoff. ## Verification - `pnpm exec vitest run cli/src/__tests__/onboard-service.test.ts cli/src/__tests__/runtime-info.test.ts cli/src/__tests__/onboard.test.ts cli/src/__tests__/open-url.test.ts cli/src/__tests__/service-health-check.test.ts` — 44 tests passed. - `node --test scripts/service-onboard-smoke.test.mjs` — 4 tests passed. - `pnpm -r typecheck` — passed on head `82920596a`. - `pnpm build` — passed on head `82920596a`. - `pnpm test:run` — 4,685 tests passed. The command also reported 31 failures in nine server test files outside this change. This machine generated invalid test ports above 65,535, and some project-skill fixtures resolved outside the worktree. ## Risks - Risk is low because the new handoff runs only after a successful service installation. - Onboarding can wait up to 60 seconds when runtime metadata or the health check does not become ready. - Runtime metadata is matched to the supervisor PID, so stale or foreground-process metadata is ignored. - A non-interactive terminal does not open a browser. - A failed health check or browser launch does not fail onboarding. The CLI keeps a manual URL visible. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used OpenAI Codex, GPT-5 family. The runtime did not expose the exact model ID or context window. The model used reasoning, repository tools, GitHub access, and code execution. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
268 lines
8.8 KiB
Markdown
268 lines
8.8 KiB
Markdown
# Installing Paperclip
|
|
|
|
Paperclip supports a managed installation, an ephemeral `npx` tryout, a
|
|
traditional global npm installation, and development from a source checkout.
|
|
The managed installation is recommended because it provides atomic updates,
|
|
rollback, git-ref installs, and a stable entrypoint for the background service.
|
|
|
|
## Recommended Install
|
|
|
|
On macOS, Linux, or WSL2:
|
|
|
|
```sh
|
|
curl -fsSLO https://paperclip.ing/install.sh
|
|
curl -fsSLO https://paperclip.ing/install.sh.sha256
|
|
if command -v sha256sum >/dev/null 2>&1; then
|
|
sha256sum -c install.sh.sha256
|
|
else
|
|
shasum -a 256 -c install.sh.sha256
|
|
fi
|
|
bash install.sh
|
|
```
|
|
|
|
The bootstrap script:
|
|
|
|
1. verifies that the platform is supported;
|
|
2. ensures Node.js 24.11 or newer is available;
|
|
3. delegates installation to `paperclipai install`;
|
|
4. starts interactive onboarding when stdin and stdout are terminals.
|
|
|
|
The script prints and confirms any command that requires elevated privileges.
|
|
Third-party Node.js bootstrap scripts are pinned and SHA-256 verified before
|
|
execution; the installer stops if a published script changes unexpectedly.
|
|
The `paperclip.ing` checksum detects transfer or publishing mistakes, but it is
|
|
served from the same origin as the script and is not an independent
|
|
authenticity proof. For an independently hosted source, download a release-tag
|
|
or commit-pinned copy from GitHub, review it, and run that local file.
|
|
|
|
Use `--no-prompt` for automation and `--no-onboard` to stop after installing.
|
|
The piped form only proceeds when supported Node.js, npm, and npx are already
|
|
installed; if Node.js bootstrap is required, download the script first so the
|
|
privileged commands are inspectable before execution:
|
|
|
|
```sh
|
|
curl -fsSL https://paperclip.ing/install.sh | bash -s -- --no-prompt --no-onboard
|
|
paperclipai onboard --yes
|
|
```
|
|
|
|
If the vanity installer endpoint is unavailable, fetch the same
|
|
release-controlled source from GitHub raw content:
|
|
|
|
```sh
|
|
raw_base=https://raw.githubusercontent.com/paperclipai/paperclip
|
|
curl -fsSL "$raw_base/master/scripts/install.sh" | bash
|
|
```
|
|
|
|
For audits or incident response, pin the raw URL to a release tag or commit SHA
|
|
instead of `master` and download it first. That immutable GitHub URL provides a
|
|
separate delivery path from `paperclip.ing`; do not treat a checksum served by
|
|
the same origin as the artifact as an independent trust anchor.
|
|
|
|
Each installer flag also has a `PAPERCLIP_INSTALL_*` environment-variable
|
|
equivalent. This helps where passing arguments through a pipe is awkward.
|
|
|
|
## Managed Install Layout
|
|
|
|
Managed code is separate from instance data:
|
|
|
|
```text
|
|
~/.paperclip/cli/
|
|
├── install.json
|
|
├── current -> installs/npm/2026.720.0
|
|
└── installs/
|
|
├── npm/<version>/
|
|
└── git/<sha12>/
|
|
|
|
~/.local/bin/paperclipai
|
|
```
|
|
|
|
The `paperclipai` shim remains stable while `current` switches atomically
|
|
between complete payloads. Paperclip keeps the two previous managed payloads
|
|
for rollback. Configuration, databases, uploads, logs, secrets, and workspaces
|
|
remain under `~/.paperclip/instances/` and are not stored inside CLI payloads.
|
|
|
|
If `~/.local/bin` is not on `PATH`, the installer offers to update the relevant
|
|
shell startup file when running interactively. Non-interactive installs print
|
|
the exact `export PATH` command instead of editing shell files silently.
|
|
|
|
## Install Sources
|
|
|
|
Install the current stable release:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install
|
|
```
|
|
|
|
Install canary or pin an exact published version:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install --canary
|
|
npx --registry https://registry.npmjs.org paperclipai install --version 2026.720.0
|
|
```
|
|
|
|
Install a branch, tag, or commit from GitHub:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install --ref master
|
|
npx --registry https://registry.npmjs.org paperclipai install --ref v2026.720.0
|
|
npx --registry https://registry.npmjs.org paperclipai install --ref <commit-sha>
|
|
```
|
|
|
|
Use a fork by adding `--repo owner/repository`:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai install \
|
|
--repo your-org/paperclip \
|
|
--ref your-branch
|
|
```
|
|
|
|
Git-ref installs resolve the requested ref to an exact commit before building.
|
|
Review and trust the repository and ref: installing a git ref executes that
|
|
revision's package installation and release build scripts on your machine.
|
|
|
|
## Onboarding And The Service
|
|
|
|
Run onboarding after a non-interactive installation:
|
|
|
|
```sh
|
|
paperclipai onboard
|
|
```
|
|
|
|
Interactive onboarding asks whether Paperclip should run as a background
|
|
service when the platform supports one. Automated onboarding deliberately does
|
|
not install a service unless explicitly requested:
|
|
|
|
```sh
|
|
paperclipai onboard --yes # configure only; no service install
|
|
paperclipai onboard --yes --install-service # explicit automation opt-in
|
|
paperclipai onboard --yes --no-install-service
|
|
```
|
|
|
|
After onboarding installs and starts the service, it waits for the service to
|
|
report its selected runtime port and then prints the dashboard URL. Interactive
|
|
terminals open that URL in the default browser; headless and non-interactive
|
|
runs print the URL without trying to launch a browser.
|
|
|
|
Service commands are namespaced:
|
|
|
|
```sh
|
|
paperclipai service install
|
|
paperclipai service status
|
|
paperclipai service start
|
|
paperclipai service stop
|
|
paperclipai service restart
|
|
paperclipai service logs -f
|
|
paperclipai service uninstall
|
|
```
|
|
|
|
Paperclip uses a systemd user service on Linux and WSL2 systems with user
|
|
systemd, and a LaunchAgent on macOS. Containers, WSL1, and systems without a
|
|
supported user service manager receive foreground `paperclipai run` guidance
|
|
instead of a hard failure.
|
|
|
|
The service uses the stable managed-install shim, restarts after crashes, and
|
|
can start on login. On Linux, service installation may offer to enable user
|
|
lingering so it can continue without an active login session. The command
|
|
explains and confirms that system-level action before running it.
|
|
|
|
Use one server process per instance. `paperclipai run` refuses to start when
|
|
the same instance is already supervised; stop the service first or use
|
|
`--force` only when you intentionally accept the single-writer risk.
|
|
|
|
## Update And Rollback
|
|
|
|
Update according to the source and channel recorded in the install manifest:
|
|
|
|
```sh
|
|
paperclipai update
|
|
```
|
|
|
|
Select a different release source explicitly:
|
|
|
|
```sh
|
|
paperclipai update --latest
|
|
paperclipai update --canary
|
|
paperclipai update --version 2026.720.0
|
|
```
|
|
|
|
Managed updates create a database backup before switching payloads, verify the
|
|
new CLI, atomically flip `current`, and restart an installed service. A failed
|
|
install or verification leaves the previous payload active.
|
|
|
|
If the service is stopped, start it with `paperclipai service start` before
|
|
updating so Paperclip can take the safety backup. Use
|
|
`paperclipai update --no-backup` only when you intentionally accept updating
|
|
without that rollback safeguard. A never-onboarded instance with no config or
|
|
instance data skips the backup automatically because there is nothing to save.
|
|
|
|
Roll back to the previous retained payload:
|
|
|
|
```sh
|
|
paperclipai update --rollback
|
|
```
|
|
|
|
The `upgrade` command is an alias for `update`. Exact versions and commit SHAs
|
|
are pinned; provide a new target when you want them to move.
|
|
|
|
## Other Installation Methods
|
|
|
|
Ephemeral tryout with no managed install:
|
|
|
|
```sh
|
|
npx --registry https://registry.npmjs.org paperclipai onboard --yes
|
|
```
|
|
|
|
Traditional global npm install:
|
|
|
|
```sh
|
|
npm install --global --registry https://registry.npmjs.org paperclipai
|
|
paperclipai onboard
|
|
```
|
|
|
|
Source checkout for development:
|
|
|
|
```sh
|
|
git clone https://github.com/paperclipai/paperclip.git
|
|
cd paperclip
|
|
pnpm install
|
|
pnpm dev
|
|
```
|
|
|
|
The managed `paperclipai update` command can update managed and global npm
|
|
installs. For source checkouts it reports the appropriate git workflow instead
|
|
of modifying the checkout automatically.
|
|
|
|
## Diagnose An Installation
|
|
|
|
Run:
|
|
|
|
```sh
|
|
paperclipai doctor
|
|
paperclipai service status
|
|
```
|
|
|
|
`doctor` checks the managed install store, manifest, `current` link, shim,
|
|
`PATH`, Node.js version, and service state. Service diagnostics cover unit-file
|
|
presence and drift, running state, configured port ownership, and the running
|
|
server version.
|
|
|
|
The CLI and server also print a non-blocking startup warning when Node.js is
|
|
below the supported minimum. Upgrade Node.js with a version manager or follow
|
|
the downloaded `install.sh` workflow under **Recommended Install**. Do not use
|
|
the piped form for this repair because it requires a supported Node.js runtime
|
|
before it starts.
|
|
|
|
## Uninstall
|
|
|
|
Remove the background service and managed CLI payloads:
|
|
|
|
```sh
|
|
paperclipai service uninstall
|
|
paperclipai uninstall
|
|
```
|
|
|
|
`paperclipai uninstall` removes the managed shim, manifest, and CLI payloads.
|
|
It deliberately preserves `~/.paperclip/instances/`, including configuration,
|
|
databases, uploads, logs, secrets, backups, and workspaces. Back up and remove
|
|
that data separately only when you intend to delete the Paperclip instance.
|