Skip to content

Connecting a daemon

A daemon on your machine can join your organization in the cloud. It opens one outbound connection; your people reach it through the app from anywhere, and its memory never leaves its machine.

This is the with you choice of where your memory lives.

  1. On the daemon’s machine:

    Terminal window
    pcx connect

    It prints a short code and a link. Nothing secret is shown or copied.

  2. An owner or admin of the organization opens the link in the app, signed in. The app shows the daemon’s name, its machine and the code; check that the code is the one in your terminal. Choose which of the daemon’s workspaces join: the others stay local, and nobody in the organization sees them. The approval is audited.

  3. pcx connect receives its token once and keeps it in ~/.post-cortex/connect.json (mode 0600). From then on the daemon connects at every start.

  • The daemon’s space shows in the organization menu of the app and in Connections, which says whether it is online. When it is off, its space says so and when it last connected.
  • Its own work does not depend on the connection: the team’s turns, the scheduler, webhooks and channels run whether or not it is connected.
  • Webhooks can reach it through the cloud, so its machine needs no open port.

An organization in the cloud keeps its board, memory, team and agents there, but has no files, shell or git of its own: those tools reach only the machine they run on. A daemon lends them as a runner, much as a self-hosted runner does for a CI service.

Terminal window
pcx connect --runner
  • In its daemon.toml, [runner] names the tool modules it lends (tools-fs, tools-shell, tools-git), each with the directories it may reach, and the paths no module ever reaches (by default .env, keys, .ssh and other credentials).
  • The owner or admin who approves it chooses the workspace it serves: a team’s. One runner per organization.
  • The team’s agents then call those tools as their own, and they run on the runner’s machine, in its sandbox and under its grants, which nothing in the cloud widens. A board’s repository and each task’s worktree are on that machine; a push goes from it with its own ssh agent.
  • A runner is never a door to the daemon’s memory: every call that is not one of its lent tools is refused.
  • When it is off, its tools fail at once with runner offline, and a task waits for it.

The token’s hash, the daemon’s name, machine and version, the workspaces it offered, whether it is online and when it was last seen, usage counts, and the audit of pairing, approval and revocation.

Never: records, messages, documents, embeddings, files or secrets. Nothing logs a request’s body.

Run pcx connect --off on the machine, or revoke the daemon in the app under Connections. The connection closes at once, and both are audited.