## Thinking Path > - Paperclip manages agents that must write work and report task outcomes through its API. > - Local adapters select an execution engine and its permission settings. > - A higher ACP Node requirement can make an unchanged installation lose access to its default engine. > - The adapter then silently selects CLI, which can change permissions and block API access. > - This pull request keeps the engine choice fixed and reports missing prerequisites before work starts. > - It also gives explicit Codex CLI runs usable defaults and keeps managed services on a supported Node runtime. ## Linked Issues or Issue Description Refs #12215. Related changes: #11792 raised the Node requirement; #13094 addressed separate runner networking behavior. This change fixes the engine-selection and managed-launcher paths. **What happened?** An unchanged agent could switch from ACP to CLI after an upgrade. Codex CLI then used read-only permissions with networking disabled. The run could finish without updating its task. Repeated recovery attempts used the same unavailable setup. Managed updates also skipped the Node check and did not refresh old launchers. **Expected behavior** An unavailable engine must fail with a clear setup error. It must not silently select another engine. Explicit CLI runs must be able to write workspace files and call the API unless the operator configures stricter settings. Managed updates must validate Node and keep child tools on that runtime. **Steps to reproduce** 1. Run an ACP-default agent under Node 22 after the ACP minimum rises to 24.11. 2. Leave the engine unset and disable the approval/sandbox bypass. 3. Observe the old adapter select CLI and fail to write task disposition through the API. 4. Start a managed service with an old launcher and a supervisor PATH that selects a different Node for child tools. ## What Changed - Remove automatic engine fallback for Codex, Claude, Gemini, and Kimi. Check prerequisites for default and explicit ACP selections. - Return a configuration error with proof that provider work did not start. Stop automatic continuation retries for this error. - Enable Codex ACP workspace networking at the actual turn boundary. Upstream mode presets otherwise force it off even when config.toml enables it. Preserve explicit network denial and read-only mode. - Set workspace-write and network access defaults for explicit Codex CLI runs. Preserve explicit sandbox modes, profiles, and network restrictions. - Pin the validated Node directory in managed launcher PATH. Refresh legacy launchers during installs and npm/Git updates. - Reject updates on unsupported Node. Keep update checks, dry runs, and rollback available. - Synchronize the qualified Codex ACP executable identity across server, TypeScript runner, Rust runner, and provider-pack launch paths. - Add regression tests and update engine and installation documentation. ## Verification - [Full CI passed on the final head](https://github.com/paperclipai/paperclip/actions/runs/34387099695): typecheck, build/native runner verification, all general and serialized test shards, all browser shards, release registry, canary dry run, and policy checks. - Greptile: 5/5 on `2c1d6e2815830a5cd39e36c8a082cc0c4441b6c0`, with no unresolved review findings. Security gates are green. - Full workspace typecheck and build also passed locally. The final deployed Linux build passed. - Full Codex, Claude, Gemini, and Kimi source test suites: 804 passed, 2 skipped. Installer, updater, and launcher tests: 47 passed. Installed ACP turn-boundary tests: 3 passed. ACP packaging tests: 14 passed. Focused recovery classification tests also passed. - Real Linux Codex CLI runs, both fresh and resumed, wrote a workspace file and reached the control-plane health API with the new defaults. - Explicit read-only and network-disabled control probes retained those restrictions. - A real ACP run on the final deployed Linux build wrote a file and reached the control-plane API with HTTP 200, without engine fallback. The same probe failed DNS before the turn-policy patch. - Executable-identity and installed-policy contracts: 12 passed. Affected native server tests: 197 passed. Runner factory tests: 21 passed. Rust qualification and native provider integration tests: 11 passed. - Deployed the production changes to a Linux service on Node 24.20 after a verified database backup. Health, bootstrap readiness, static UI, executable/cwd identity, and guarded restart checks passed. The restart lost no runs. - Corrected stale Kimi skill-default and Gemini remote-archive fixtures; both suites pass. ## Risks - Default or legacy auto engine settings now fail when ACP is unavailable. Operators who intend to use CLI must select it explicitly. - Codex CLI now permits workspace writes and networking by default, and ACP workspace-write turns permit networking by default. Explicit operator sandbox settings remain authoritative. - Old managed launchers keep their pinned Node until they are reinstalled under a supported runtime. An old updater cannot repair itself; the documentation gives the current installer command. - Custom service wrappers and global/source installations must configure their runtime PATH. No database migration is required. ## Model Used OpenAI Codex, based on GPT-6, with reasoning, repository inspection, shell execution, and test tools. The exact serving model identifier and context-window size are not exposed in this session. ## 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>
11 KiB
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:
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:
- verifies that the platform is supported;
- ensures Node.js 24.11 or newer is available;
- delegates installation to
paperclipai install; - 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:
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:
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.
Codex ACP workspace sessions enable networking so agents can report task outcomes.
To disable it explicitly, set extraArgs to
["-c", "sandbox_workspace_write.network_access=false"], or set
env.PAPERCLIP_CODEX_ACP_NETWORK_ACCESS="false". Execution-target network denial
also remains enforced. Read-only ACP mode remains read-only.
Node runtime used by background services
Check the Node executable used by the running service, not only node --version
in an interactive shell. Systemd and launchd do not load shell version-manager
configuration. A newer Node installed elsewhere does not upgrade a running
service or change a custom startup script's PATH.
Managed installs pin the validated Node executable in the paperclipai shim
and prepend its directory to PATH for child tools, including ACP servers with
an /usr/bin/env node shebang. Re-run the installer using the supported
Node runtime after changing runtime installations, then restart the service.
For example, put the supported Node's bin directory first on PATH and run
npx paperclipai@latest install --yes. Do not use the old managed shim to
re-pin Node: it intentionally continues launching its previously pinned runtime.
Installs and updates refresh existing managed shims in place. Updates reject an
unsupported running Node before installing or activating a payload; read-only
update checks and rollback remain available for recovery. Global npm installs and
source checkout services must configure their own executable and child-process PATH.
For custom service wrappers, use an absolute, supported Node executable and put
that executable's directory first on PATH. Keep required existing PATH entries.
On Linux, verify the running executable with /proc/<server-pid>/exe; an
interactive shell version check alone is insufficient. Use the guarded restart
procedure in DEVELOPING.md when jobs are active.
Legacy local adapters default to ACP, including configurations with no engine
field or the old auto value. An unavailable ACP runtime fails the run and the
agent environment test with a setup error; it never silently changes engines.
Repair the reported prerequisite or explicitly select engine: cli. Local
filesystem/network confinement and in-place Codex workspaces require explicit
CLI selection. CLI sandbox defaults and explicit restrictions are described in
the adapter configuration documentation.
Managed Install Layout
Managed code is separate from instance data:
~/.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:
npx --registry https://registry.npmjs.org paperclipai install
Install canary or pin an exact published version:
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:
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:
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:
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:
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:
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:
paperclipai update
Select a different release source explicitly:
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:
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:
npx --registry https://registry.npmjs.org paperclipai onboard --yes
Traditional global npm install:
npm install --global --registry https://registry.npmjs.org paperclipai
paperclipai onboard
Source checkout for development:
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:
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:
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.