Permissions and data boundaries

What runs on your machine

Three programs. Only the first is always present.

af-ctld — lifecycle daemon. Starts at login; holds one outbound connection to the message server; watches local sessions; performs six lifecycle actions. Makes this machine reachable from your other machines.

Launcher — one per session. Started by imclaude or imcodex. Runs the AI tool as a child process; assigns the session identity; delivers messages; exits with the session.

af-msgd — optional message server. Runs only on the machine selected as the LAN server. One per LAN; absent from the other machines and from cloud-relay setups.

af-ctl status
af-ctl ps

Network

Nothing listens on a public interface unless you made this machine the message server.

File receipt: no open port; every transfer uses outbound connections. Firewall: one rule — port 26800 on the selected message-server machine.

LAN discovery: multicast DNS on 224.0.0.251, the standard address used by Macs and network printers. A pinned address from af-ctl setup --msg-server disables discovery.

lsof -iTCP -sTCP:LISTEN -P
ss -ltnp
netstat -ano

What this machine calls out to

Three Woodor endpoints, all over TLS:

• wss://msg.woodor.ai — cloud message server; paid plans only. Free-plan and LAN traffic never reaches it.
• https://woodor.ai/api — activation only: once at activation, once after a machine rename.
• https://dl.woodor.ai/fleet/latest.json — static update manifest; checked at most once every 24 hours. This is the update request the product already needs, not an extra analytics request. Its user agent contains only the Agent Fleet version, operating system, and architecture. No identifier or request body: no licence, machine name, path, or username.

No telemetry, analytics, usage reports, heartbeats, or licence polling. Installation totals by platform and version are counted from our own server access logs for the existing update request; the client does not report them. An expired subscription stops connecting and falls back to the LAN; no licence poll is required.

Files

What it owns

All Agent Fleet data: ~/.agent-fleet/ (%USERPROFILE%\.agent-fleet\ on Windows).

• settings.json — how this machine is set up.
• secrets.json — machine credential, this machine's private key, and your account's content key. Mode 0600. See “What 0600 does and does not do” below.
• inbox/<sender>/ — files other sessions sent you.
• logs/ — the three programs' logs.
• sessions/ — one record per running session.

What it changes outside its own directory

Skills only. af-ctl setup installs two message and file-transfer instruction pages in the AI tool's skills directory. Agent Fleet marks its files. Unmarked and edited skills are never overwritten or deleted. Uninstall removes only Agent Fleet's marker and page.

What a session is allowed to do

Required for unattended Agent Fleet actions:

• Commands: am, af-ctl.
• File write: handoff card.

Sessions can be launched only from the local machine or an authenticated remote console.

Setup records the choice; the AI tool's configuration is never read, edited, or restored. Allowed permissions are supplied at session launch and expire with the session.

Per-tool delivery:

• Claude Code: additional settings file with the exact commands above. Permission lists merge; they do not override. Existing permissions cannot be removed; permission mode is unchanged; an existing permission-check bypass remains active.
• Codex: launch values override the user's configuration for the supplied keys. Two are supplied: approval_policy = never and network access inside the sandbox — both named in the setup prompt. Network access is required for am to reach a message server.

Sandbox mode: not supplied. Supplying it would set the user's confinement policy inside Agent Fleet-launched sessions only, invisible in the user's own configuration. A read-only sandbox blocks handoff-card writes; Agent Fleet does not bypass it.

Declined: no Agent Fleet permissions supplied. Approval-prompt behavior remains entirely under the user's configuration.

What it reads

Session state from local transcripts; metadata only: last speaker, time, model, token counts, compaction count. No content. Local processing only. Transcripts are never uploaded and never leave the machine.

What we never touch

Delivered files: ~/.agent-fleet/inbox/, never a session working directory. Working directories are often git repositories. No post-delivery reads, moves, or deletes. Duplicate names receive a number; no overwrite.

Who can control this machine

af-ctld: six lifecycle actions. launch starts a session; exit and restart end or restart one. Authorization is origin-based.

Same machine. af-ctl agent → daemon over loopback. Local sessions only; nothing leaves the machine.

Another LAN machine: no control. The local message server rejects lifecycle requests without routing them. LAN peers can exchange messages and files, but cannot start, stop, or restart each other's sessions.

Cloud relay: authenticated console only. Machine and session connections cannot issue lifecycle requests, including connections on the same account. Rejected before delivery to the target daemon.

Authorization source: connection credential, never the self-asserted name. Any caller can choose any name. The server derives origin from the credential and overwrites caller-supplied origin before daemon delivery.

What the cloud relay can see

Paid plans only. Free-plan and LAN-only traffic never reaches Woodor servers.

Message body: encrypted before transmission; content key available only on your machines. Woodor servers hold encrypted key copies but cannot decrypt them or the message body.

Envelope: not encrypted. Required for routing, fan-out, and retention. Contents:

Project and session names: cleartext message addresses. Use a non-sensitive project name when required.

Transferred files: cleartext name and size; encrypted bytes. Bytes remain until recipient collection, then immediate deletion. Uncollected bytes: 7-day deletion.

Plus message retention: 30 days for offline-machine catch-up, then deletion.

Woodor-visible data may be disclosed when legally compelled.

Keys, and what 0600 does not do

One account content key: random, fixed, never available to Woodor in readable form. New machines receive a copy from an existing machine. Recovery code: shown once at setup, never sent to Woodor, required after loss of every machine.

secrets.json: mode 0600; unreadable by other OS user accounts. Not protected against:

• Off-machine copies: backups, sync folders, support bundles, accidental repository commits. Permission bits do not travel with the file.
• Processes under the same OS account. Unattended decryption requires local access; another process under that account has the same access. A system keychain changes storage location, not access.

Revocation limits this risk. Lost machine: deactivate it from the account page; its credential stops working.

In one paragraph

One background process; outbound connection; no listener unless selected as the message server; local session-metadata reads; one storage directory. Paid plans: message relay; Woodor sees sender, recipient, and time — never message content. The local setup prompt lists requested AI-tool permissions.