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.
Pairing
Section titled “Pairing”-
On the daemon’s machine:
Terminal window pcx connectIt prints a short code and a link. Nothing secret is shown or copied.
-
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.
-
pcx connectreceives its token once and keeps it in~/.post-cortex/connect.json(mode 0600). From then on the daemon connects at every start.
After connecting
Section titled “After connecting”- 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.
A runner for your organization
Section titled “A runner for your organization”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.
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,.sshand 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.
What the cloud keeps
Section titled “What the cloud keeps”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.
Ending it
Section titled “Ending it”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.