Local Communication

The pipe-based command and listener implementations exchange local messages with the agent core using interprocess communication (IPC) facilities. This page distinguishes Windows named pipes from the first-in, first-out (FIFO) objects used on the supported Portable Operating System Interface (POSIX) platforms.

Local and External Communication

Local IPC connects an ExecUnit to its hosting agent core. A listener's external transport connects it to Command and Control (C2) or another transport endpoint. These are separate channels, even when both happen to use technology described as a pipe.

The local channel can be used when the ExecUnit and core share a process. Its purpose is to provide the component communication boundary independently of the execution context.

Commands and listeners use the same broad local transport model, but different message contracts. The command protocol, listener protocol, and Type-Length-Value (TLV) reference own the detailed message and encoding definitions.

Execution Without a Local Channel

The host also has a no-IPC strategy. It provides no local channel for configuration, results, or listener exchanges. This is a separate communication choice; it does not establish that a component expecting pipe messages can operate without them, or that standard output automatically replaces those messages. The pipe-based defaults described below depend on their local communication contract.

Windows and POSIX Models

Windows provides a duplex connection through one named-pipe instance. The POSIX implementations use two directional FIFOs to provide communication in both directions.

Property	Windows	Linux, FreeBSD, and macOS
Operating-system object	A Windows named pipe.	Two filesystem FIFOs, or named pipes.
Direction	One duplex connection carries both directions.	Each FIFO carries one direction.
Naming	A name in the Windows pipe namespace.	A filesystem path for each FIFO.
Access control	Pipe security and the identities of the participating processes.	Filesystem permissions, directory access, and process identities.
Lifetime	Pipe handles and the named-pipe instance.	Open file descriptors and filesystem entries have distinct lifetimes.

Windows Named Pipes

The current host uses byte-oriented Windows named pipes for local IPC. Duplex means that both participants can send and receive through the connection. It does not mean that one read returns one complete application message.

A Windows pipe name identifies an operating-system communication object rather than a regular file. The connection can become unavailable when a peer closes its handle or exits, or when an outstanding operation is cancelled. Establishing a connection and completing an exchange are separate observations.

Do not confuse this local channel with a Server Message Block (SMB) relay listener. The latter has its own transport role and external participants. A local pipe used by any ExecUnit does not make that ExecUnit an SMB listener.

POSIX FIFOs

A FIFO is a special filesystem object through which bytes flow between readers and writers. It is not a regular file containing saved messages, and it is not a Unix-domain socket. The supplied Linux, FreeBSD, and macOS implementations use one FIFO for each direction of the local exchange.

Read and write describe a participant's perspective: what one side writes, the other side reads. Keeping those perspectives clear is important when interpreting logs or diagrams. The existence of both paths does not prove that both peers have usable open endpoints.

FIFO access depends on the containing directories as well as the FIFO entries themselves. Filesystem permissions and the identities of the participating processes therefore matter even though the communication stays on one machine.

Closing a file descriptor and removing a FIFO path are different actions. A path can remain after communication has ended, and an open endpoint can outlive removal of its path. Consequently, an existing path is not a health signal and does not establish that a current invocation owns it.

Stream Behavior

Both platform models carry byte streams beneath the application protocol. Operating-system input/output (I/O) boundaries do not define logical message boundaries: a read can provide only part of the expected data, and multiple application messages can be available together. A successful write also does not establish that the peer has processed the data.

Pipes have finite buffers. A writer can wait when the peer is not consuming data, while a reader can wait when no data is available. On POSIX systems, opening a FIFO can itself wait for the matching peer. Lack of immediate progress is therefore not sufficient to distinguish ordinary waiting from a missing peer or a shutdown problem.

These are operating-system stream properties, not a guarantee that every shipped helper handles every partial-I/O or cancellation case uniformly. Consult Limitations and Diagnostics for the implementation boundaries.

Ownership and Disconnection

The host's local communication layer owns the endpoints it creates, while each component owns the handles or descriptors it opens. Communication activity and its resources need compatible lifetimes: a worker still using a channel is different from a worker that has finished, even if neither is currently producing output.

For a command, a disconnect does not substitute for a success or failure outcome. For a listener, a local disconnect is distinct from loss of the external connection. Keep those observations separate when diagnosing incomplete results or an unavailable transport.

Abnormal exits and incomplete cleanup can leave resources behind, particularly filesystem FIFO entries. The platform pages describe the supported context and lifetime boundaries: Windows, Linux, FreeBSD, and macOS.