Why AxiOwl Does Not Need an Always-Running Daemon

Why AxiOwl Does Not Need an Always-Running Daemon

AxiOwl does not need an always-running daemon to do its current job. The active Windows implementation is built around explicit process entry points: a CLI command, a native MCP server mode, a delivery-worker mode, durable registry files, and evidence logs. A host starts the process it needs, AxiOwl resolves sender and target identity, records a clear handoff receipt, and then starts provider delivery through a worker process when delivery is ready.

That is different from saying AxiOwl has no place reserved for a local service. The code and README reserve 127.0.0.1:37661 as the local service endpoint. The same README and status implementation also state the current behavior exactly: the local always-running service is not implemented yet, and the CLI is running the direct local pipeline skeleton. Today, the endpoint is a reserved product boundary, not a daemon that must already be listening before AxiOwl can send, create, list, discover, or expose MCP tools.

Current Status

The Windows README lists the current implementation status plainly:

The runtime split is also explicit. The Windows build is the local coordinator, registry owner, and outbound SSH remote provider. The Linux build is a remote Codex endpoint, relay-session receiver, and Codex CLI delivery target only. The installed Windows package puts axiowl.exe under %LOCALAPPDATA%\AxiOwl\bin, registers MCP configuration for supported hosts, and uses command modes such as:

axiowl send --to <agent> --stdin
axiowl create --provider <provider> --name <agent> --stdin
axiowl mcp-server
axiowl delivery-worker --request <request-json-file>
axiowl relay-session --stdio
axiowl status

Those are not service-control commands. They are executable modes. AxiOwl starts, does the requested work, and exits or stays alive only for the lifetime of a stdio session that a host launched.

The CLI Runs the Pipeline Directly

The send path is the clearest example. In cli.cpp, run_send builds a MessageRequest from command-line flags, reads the message body from --stdin when that flag is present, ensures state directories exist, constructs a MessagePipeline with the local registry and evidence log, and calls pipeline.send(request).

There is no socket client call to the reserved service endpoint in that path. There is no "wake the daemon" step. The CLI owns the local request lifecycle for that invocation.

That directness is useful because the pipeline can enforce AxiOwl's real boundaries immediately:

  1. Reject empty target names.
  2. Reject empty message bodies.
  3. Resolve the sender from explicit identity or the registry.
  4. Run targeted discovery only when the target is missing.
  5. Reject known-but-not-sendable targets.
  6. Accept the request only after target resolution succeeds.

Only after those checks does the receipt become accepted_by_axiowl. The code records the receipt boundary as after_target_resolution_before_delivery_worker_or_provider. That wording matters. AxiOwl acceptance is not the same thing as proof that the provider accepted delivery, and it is not the same thing as proof that a recipient replied.

The Delivery Worker Is Transient

Current AxiOwl also avoids putting provider delivery inside a resident daemon. After the message pipeline builds the final visible body and provider request, it calls handoff_provider_request_through_delivery_worker.

The delivery worker handoff writes a request JSON file and starts:

axiowl delivery-worker --request <request-json-file>

On Windows, the process utility starts that worker with CreateProcessA using CREATE_NO_WINDOW | DETACHED_PROCESS. The main send path can return an AxiOwl handoff receipt while the worker owns provider dispatch. Validation paths can run the same worker synchronously with --validate-only.

That gives AxiOwl a practical middle ground. The send command does not need to stay attached to every provider write, but the project also does not need a permanent background service just to begin delivery. Each delivery handoff has a request file, a message ID, a run ID, delivery-stage logging, and worker result events. Failures remain inspectable without forcing all local behavior through a long-lived process.

MCP Is Also Process-Scoped

AxiOwl's MCP integration follows the same shape. The command is:

axiowl mcp-server [--host <host>] [--provider <provider>]

An MCP-capable host starts that process and communicates over stdio. The server advertises tools such as axiowl_send_message, axiowl_create_agent, axiowl_whoami, axiowl_list_agents, axiowl_status, and axiowl_version. For axiowl_send_message, the tool handler resolves host identity, registers the sender when possible, builds an internal CLI argument list, appends --stdin, and calls the CLI path through run_cli_captured.

That means MCP does not require a separate daemon either. The host already has a process relationship with AxiOwl. The important MCP value is sender identity and typed tool structure, not a resident network listener. The tool description is careful about the receipt boundary: success is an MCP-to-AxiOwl handoff receipt only; provider delivery and reply are not implied.

The MCP conformance test reinforces this lifecycle. It starts axiowl.exe mcp-server --host codex --provider codex as a child process with redirected standard input and output, sends initialize, tools/list, and tools/call, then closes stdin and expects the MCP process to exit cleanly. It also tests both newline-delimited JSON-RPC and framed Content-Length messages. That is process-scoped server behavior, not a system daemon contract.

Why This Is the Right Current Shape

An always-running daemon can be useful when one process must own shared state, hold persistent connections, arbitrate queue ordering, or provide a stable local API to many independent clients. AxiOwl has a reserved endpoint for that future boundary, and older plan material discusses an always-running service. But the active implementation has not made that service the source of truth.

The current source of truth is simpler and easier to audit:

That design keeps failure modes visible. If the sender is unresolved, send fails loudly instead of queuing a mystery request. If the target is missing, AxiOwl reports the discovery result instead of pretending a daemon accepted work. If provider delivery is not yet proven, the receipt says so by staying at the AxiOwl handoff boundary.

It also makes installation less fragile. The Windows installer needs to place the executable, packaged provider integration pieces, MCP config, extensions, patches, logs, and remote Linux payload setup. It does not have to register and supervise a Windows service before AxiOwl can expose tools or run CLI commands. A host can start mcp-server when it needs tools; a human or script can call send; the pipeline can launch delivery-worker when provider dispatch is ready.

What the Reserved Endpoint Means

The reserved endpoint is still meaningful. service_config.hpp defines:

127.0.0.1:37661

axiowl status prints that value as the local service endpoint. It also prints the current local service status:

Local service: not implemented yet; CLI is running direct local pipeline skeleton

That is the exact current state. The product has a named place where a local service can live later, but the current Windows implementation does not depend on that process. If a future AxiOwl service owns queueing or long-lived routing, it should preserve the same evidence boundaries that exist now: local acceptance, provider handoff, provider delivery result, and MCP reply are separate facts.

Closing

AxiOwl does not need an always-running daemon because the active implementation already has explicit, inspectable process boundaries. The CLI invokes the message pipeline directly. The MCP server is launched by the host over stdio. Provider delivery is handed to a transient delivery-worker process. The registry, evidence log, delivery log, and status output make the lifecycle visible without requiring a resident background service.

The important fact is not that AxiOwl will never have a local service. The important fact is that current AxiOwl behavior does not hide behind one. The reserved endpoint is present, but today's product works through direct CLI, stdio MCP, registry-backed identity, and logged delivery handoff.

Sources read

Image prompt:

Create a polished graphic image related to: AxiOwl working without an always-running daemon.

Subject: a central command-line terminal launching three short-lived glowing process blocks marked only by simple geometric icons, with one reserved but inactive local socket pedestal in the background, no readable text or logos.
Style: halfway between a clean symbolic icon and a realistic product/technical illustration; professional SaaS/technical marketing style; crisp edges; high detail; no text; no logos.
Background: solid #00ff00 chroma key green screen background covering the full canvas edge to edge.
Restrictions: no owl, no axolotl, no birds, no animals, no mascot, no text, no watermark.

Tagged