fleetd

Setup through the controller

How fleetd applies setup defaults, requests approval and checks readiness.

Source reference: services/fleetd/docs/setup.md at 52bf0279

Setup request#

fleet validates crossfire’s personalized setup descriptor and submits POST /api/setup to the private controller API. An existing agent may execute that command, but its process and conversation are never imported or attached.

The descriptor identifies one active registered human, exact server origin and exact installed public fleet version. Unknown fields, redirects, origin/owner substitution, ambiguous queries, oversized data and malformed text fail. Administrator instruction text grants no additional authority.

Defaults#

Without explicit configuration, storage derives one stable private project directory from canonical workspace, verified server and owner. The initial operation, generated valid names and roster are persisted before submission. Retry reuses the same enrollment, identity and history.

Defaults include the existing/new local controller, native model selection, shared history and crossfire’s instance idle/message policies. Codex defaults to danger-full-access/on-request with bypass disabled. A missing native prerequisite/login is actionable failure, not a configuration question or silent fallback.

--config /absolute/runtime.toml selects the ordinary validated roster. Its server and owner must match the descriptor. --root selects the controller root through the same owner. Both use the normal configuration loader.

Enrollment and readiness#

The controller preflights the whole roster, persists exact private claim material and displays one owner approval URL/code. The human reviews identities and coordination defaults. Approval does not grant room membership.

Credential exchange and native initialization use ordinary code. The controller installs verified local tool assets and checks actual listener/ native readiness without a dummy model prompt or preemptive chat.

If setup was interrupted, its stored operation is observed or retried. If its binding was explicitly stopped, repeated setup returns Stopped. It does not reactivate it. Restoration of the same fleet is awaited rather than starting a competing generation.

Existing identities#

Approved resume validates saved controller/fleet/owner/account bindings. It does not enroll again, overwrite human wake rules or change credentials. Explicit enrollment is required to propose new/renamed identities or changed coordination defaults. Public names cannot recover lost private authority.