Paperclip finds its doctor can block a valid global install

paperclipai/paperclip issue #11755 is the inspected primary source: “doctor blocks server start on global npm installs — "Managed install manifest" check false-positives, and the commands it points to (install/update/service) are missing from the same release.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- paperclipai/paperclip issue #11755 was created 2026-08-20T00:16:46Z and was open at inspection; its title is “doctor blocks server start on global npm installs — "Managed install manifest" check false-positives, and the commands it points to (install/update/service) are missing from the same release.” - paperclipai/paperclip PR #11753 was created 2026-08-19T23:48:55Z and was open at inspection; its title is “fix(runtime): stop workspace restart and git-scan churn.” - paperclipai/paperclip PR #11752 was created 2026-08-19T23:41:55Z and was open at inspection; its title is “fix(workspaces): seed managed worktrees when the base checkout has no config.” - The repository reported 78900 stars, 5157 open issues, default branch master, and last push 2026-08-20T01:05:02Z. - The latest tagged-release baseline checked was v2026.817.0 published 2026-08-18T03:17:29Z.

What changed

paperclipai/paperclip issue #11755 reports: Pre-submission checklist [x] I have searched existing open and closed issues and this is not a duplicate. [x] I am on the latest released version of Paperclip (or can reproduce on master). [x] I have confirmed the error originates in Paperclip itself — not in my agent adapter, API provider, or local configuration. What happened? Summary Upgrading an existing global npm install of Paperclip from 2026.722.0 to 2026.817.0 via npm install -g paperclipai@latest (the update path documented for this install type at https://docs.paperclip.ing/how-to/update-paperclip/#global-npm-install) results in paperclipai run refusing to start the server at all. doctor reports a failing "Managed install manifest" check, even though this instance has never used the managed installer (install.sh / npx paperclipai install) — it is, and always has been, a plain npm install -g deployment behind a hand-written systemd unit. This is a production-impacting regression: any instance that fits this common, still-documented pattern (see "Global npm install" section of https://docs.paperclip.ing/reference/cli/setup-commands/) will crash-loop after updating, with no CLI-native way to recover short of downgrading. Environment paperclipai version: 2026.817.0 (upgraded from 2026.722.0) Install method: npm install -g paperclipai@latest (global npm install, not the install.sh / npx paperclipai install managed installer) OS: Ubuntu (Contabo VPS) Node.js: 24.18.0 npm config get prefix: /home/application_user/.local (the standard no-sudo prefix pattern documented on the CLI Overview page: npm config set prefix ~/.local

paperclipai/paperclip PR #11753 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work. - The server starts local workspace runtime services and reads workspace state for API routes and background cleanup. - A local runtime spawn failure could happen before the code attached its error listener. - Workspace metadata reads and the terminal-workspace reaper also ran close-readiness Git scans too often. - The live self-hosted service could restart or slow down under this scan load. - This pull request handles early spawn errors and moves Git inspection behind explicit readiness and reaper proof paths. - The benefit is a stable service and fewer Git subprocesses during normal workspace reads and repeated cleanup ticks. Linked Issues or Issue Description No public GitHub issue exists. This PR includes the bug report inline. No related PRs were found for runtime spawn EACCES git scan close_readiness churn. What happened?** A self-hosted Paperclip server could crash during local workspace runtime startup when the shell spawn failed immediately. The same server could also spend too much time in execution_workspaces.close_readiness_status Git scans during normal workspace reads and repeated terminal-workspace reaper passes. Expected behavior** The server should keep running when a local runtime shell cannot spawn. Workspace metadata reads should not run Git close-readiness scans. The terminal-workspace reaper should inspect Git only after cheap

paperclipai/paperclip PR #11752 reports: Thinking Path - Paperclip is the open source app people use to manage AI agents for work - Agents do that work in isolated git worktrees, and a managed worktree runs its own Paperclip instance with a cloned database - That clone needs a seed source, and the source must come from server-owned registration, never from state the workspace itself can rewrite - The seed-source resolver requires the registered base project workspace to hold its own.paperclip/config.json - A managed project workspace is a plain git clone, and no code writes that file into it - Every isolated worktree provision, deferred seed, and workspace repair therefore fails on a managed checkout - This pull request lets a named source supply the config when the base checkout has none - The benefit is that managed worktrees provision again, and the seed source stays server-owned Linked Issues or Issue Description No public GitHub issue exists for this problem. It is described below. What happened?** Agent runs that need an isolated worktree fail during provisioning. The provision command exits with this error (paths redacted): resolveRegisteredWorktreeSeedSource sets registeredConfigPath to /.paperclip/config.json whenever the caller names a registered base workspace. It then requires that file to exist. scripts/provision-worktree.sh applies the same rule. A managed project workspace never has that file. materializeManagedProjectWorkspace creates it with git clone

Why it matters

A recovery tool that blocks startup and points to unavailable commands turns diagnostics into an outage multiplier. Managed-install checks must agree with the package actually installed. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-20. The tagged-release baseline was v2026.817.0 published 2026-08-18T03:17:29Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/paperclipai/paperclip/issues/11755. Supporting records are https://github.com/paperclipai/paperclip/pull/11753 and https://github.com/paperclipai/paperclip/pull/11752. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Version doctor guidance against the running release, distinguish valid global installs from broken manifests, and keep workspace repair bounded and reversible. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.