@Teiluj said:

Thanks for considering packaging paperclip.

We have created a package for Paperclip and have it running but are waiting to hear from upstream before publishing it.

Before we do so, here are some concerns which people who might want to use a Paperclip package may like to read, because this app is not like most on the store.

What concerns us

• Agents run inside the app. Paperclip starts Claude Code, Codex and similar tools as processes in its own container, and upstream hands them the server's full environment. On Cloudron that includes the database credentials, and the key that encrypts every stored secret is a readable file. An agent that reads a hostile ticket or repository could take over the whole Paperclip instance.
• Upstream's sandbox cannot run here. It relies on Linux namespaces, which Cloudron app containers do not allow.
• The internal network is reachable. Any app container can reach the shared database servers and other apps directly, which also bypasses proxyAuth. An unconfined agent would be a foothold inside the server, not just inside Paperclip.
• Sign-in is email and password only. There is no OIDC yet (it is an open pull request upstream, not a plugin), and the server sends no email at all, so there is no password reset.
• It moves fast. Releases are roughly weekly, and one recent release carried 49 database migrations.

One correction to the post above: Paperclip does not use Redis or Qdrant. It needs only PostgreSQL, which the Cloudron addon provides.

How we intend to handle it

• Agents run as a separate, unprivileged user, started through a narrow sudo rule with a clean environment. They cannot read the database credentials, the encryption key or the server's memory.
• A firewall inside the container, matched on that user for both IPv4 and IPv6, blocks the internal network and outbound mail. The internet, DNS and Paperclip's own API stay open.
• Process and file-size limits apply to the agent user.
• Telemetry is off by default, and so are Paperclip's own database dumps, because Cloudron already backs up PostgreSQL.

We have tested this design on a test Cloudron. The agent user was refused on every database and every other app, saw no secrets, and still reached the internet.

Advantages

• You can run local agents without handing them the server.
• It works on stock Cloudron. It needs only the net_admin capability, which Cloudron offers to apps: no Docker socket and no privileged container.
• The listing will say plainly what an agent can and cannot reach.

Drawbacks

• All agents share one user, so one agent can read another's workspace.
• Agents can still reach the internet, so anything an agent can read, it can send out. For untrusted input, a remote sandbox or an agent in its own app (OpenClaw and Hermes Agent are already in the store) remains the better choice.
• An agent can still fill the disk.
• Board users can run any command in the app, so treat them as administrators.
• There is no SSO and no password reset until upstream adds them.
• Updates to the application (but perhaps not the package) will be frequent.