echo.ccWaitlist

Install echo.cc

echo.cc is in pre-release validation. A public installer must point to a qualified release; there is no supported public release to download yet. Do not replace a running installation until its configuration has been reviewed.

Choose where your net runs

Source build (unreleased working tree)

All configuration commands, installers, and service behaviors described below reflect the unreleased working tree. From a reviewed source checkout, build the binaries using the pinned Go toolchain:

go build -o bin/ ./cmd/ecc ./cmd/echod

Run commands directly via ./bin/ecc, or add the output directory to your executable path:

One configuration document

ecc and echod share a versioned JSON configuration document (config.json). Standard platform configuration paths are:

Configuration discovery and precedence

Configuration file selection follows a strict order:

  1. Explicit --config FILE passed before the subcommand
  2. ECHO_CONFIG_FILE environment variable
  3. config.json inside ECHO_CONFIG_DIR
  4. Platform user configuration directory

For individual settings, explicit command-line flags take precedence over present environment variables, which override values in config.json, followed by each consumer's defaults. Note that not every setting exposes a flag or environment variable; run ./bin/ecc config schema for available fields. Relative file paths in config.json resolve relative to the configuration file's directory, whereas environment paths remain caller-relative.

Managing configuration

Use the operator configuration subcommands to generate, inspect, and validate your settings:

./bin/ecc config init
./bin/ecc config validate
./bin/ecc config show
./bin/ecc config inspect
./bin/ecc config schema

ecc config init creates a starter document and refuses to overwrite an existing configuration. ecc config show prints stored settings without opening private credential files. ecc config inspect reports shared-loader input provenance (selected path, active profile, AI endpoint, and whether values come from environment, configuration, built-in defaults, or are unset) with secrets redacted; it never displays secret contents, and does not enumerate consumer-specific defaults, command-line flags, or dashboard settings. ecc config schema generates JSON Schema for editor tooling. ecc config validate checks JSON syntax, schema tags, URI structures, and cross-field constraints. It intentionally does not open credential files or verify their filesystem permissions; only the owning transports verify credentials when establishing connections.

Starter configuration example

The following example configures a local development net connecting to a local broker:

{
  "version": 1,
  "active_profile": "local",
  "profiles": {
    "local": {
      "type": "self-hosted",
      "server": "nats://127.0.0.1:4222",
      "net": "home"
    }
  },
  "logging": { "level": "info", "format": "json" },
  "metrics": { "enabled": true },
  "hooks": { "holds": "advisory" }
}

Driven agent processes enforce a 4 MiB frame limit by default (configurable via limits.drive_frame_bytes from 1024 to 16777216 bytes). Structured logging supports JSON and text output with redaction for recognized secret fields and known credentials; arbitrary payloads may contain unmodeled secrets, and automatic file retention or rotation is not implemented.

Coordinator workflows and CLI subscriptions

When driving coding agent CLIs (such as Claude Code, OpenAI Codex, or Antigravity) across your net, operators choose whichever CLI fits their installed toolset and local session context. There is no universal "best" coordinator or worker role; benchmarks reflect specific task configurations rather than general superiority.

Using agent CLIs preserves existing interactive tools, local permissions, and project context, but does not guarantee cheaper or unlimited execution:

Agent setup planning and client integration (pre-release source build)

Current source includes the pre-release setup command to plan and manage agent integrations across supported coding assistants. There is no released public installer yet; the repository installer script points to the setup plan and never modifies client configuration automatically. The examples below use ./bin/ecc directly; ensure you have built the binaries from source or added ./bin to your PATH.

Plan first

Always inspect the integration plan before modifying any configuration:

# Human-readable plan
./bin/ecc setup

# Machine-readable plan with detailed review targets
./bin/ecc setup --format json

Planning discovers agent executables on your PATH and outputs proposed native registration commands or manual review targets. It operates strictly read-only: it does not read private client settings, grant permissions, install skills, or alter any registration files.

The plan reports registration-not-inspected by design: detecting an agent binary on PATH is discovery, not proof that the client has registered echo, loaded the MCP server, or established connectivity. In JSON output, command arrays represent explicit argv vectors, not shell commands.

Isolated server verification

To verify that the local binary functions as an MCP server before integrating it with clients:

./bin/ecc setup --check

This starts the internal MCP server using disposable state and isolated configuration, calls echo_whoami, and verifies all 16 tools and 4 resources. This checks only the local binary in isolation; it does not test whether a running or newly launched Claude, Codex, Antigravity, or Goose session can discover or call the server.

Minimal apply workflow

Applying or removing MCP configuration requires an explicit --agents selection:

# Apply MCP server configuration to selected clients
./bin/ecc setup --apply --agents claude,codex,agy

# Remove only unchanged configuration owned by echo setup
./bin/ecc setup --remove --agents claude,codex,agy

Setup enforces strict safeguards: running without explicit --agents is rejected upfront; close client sessions before modifying configuration to prevent rename races; and existing unmanaged entries are preserved for manual review rather than silently adopted.

For Goose (tested on 1.52.0), the persistent MCP apply adapter is unfinished. Connect per session via --with-extension 'echo:ecc mcp' without editing YAML configuration. Because Goose resolves the inner extension executable via PATH, explicitly add the source-built binary directory to your PATH first (e.g. export PATH="$PWD/bin:$PATH" from the repository root):

export PATH="$PWD/bin:$PATH"
./bin/ecc run --tool goose --session worker-goose goose session --with-extension 'echo:ecc mcp'

Aider uses the CLI subprocess path (./bin/ecc run) without an MCP adapter.

Separate skills and permissions

Tool permissions and coordination skills are decoupled from MCP registration and must be planned and managed separately:

# Plan and review Codex executable-prefix permissions
./bin/ecc setup --permissions --agents codex

# Apply Codex permissions
./bin/ecc setup --permissions --agents codex --apply

# Plan and review canonical coordination skill targets and hash
./bin/ecc setup --skills --agents codex,goose,claude,agy

# Install canonical coordination skill
./bin/ecc setup --skills --agents codex,goose,claude,agy --apply

Security notice: Writing ~/.codex/rules/echo-ecc.rules grants an executable-prefix rule for ecc. This all-ecc permission grant includes all ecc subcommands, including ecc run and any arbitrary child commands executed through it.

See Integrations & API contracts for detailed adapter specifications, Codex permission scope, shared skill destination paths (Codex and Goose share ~/.agents/skills/echo-coordination/SKILL.md), custom root caveats, and lifecycle verification boundaries.

Protected credential references

Inline tokens, passwords, and API keys are not accepted in config.json. Authentication credentials must be kept in separate private files referenced by path (for example, credentials_file, token_file, password_file, key_file, or api_key_file).

The owning transport validates credential files at connection time against strict filesystem checks:

Member service installation and removal (pending qualification)

Native qualification of the new JSON service installers is currently pending. In the working tree, the member installers configure echod as a background user service, requiring Python 3 and either a source checkout or prebuilt binaries in ECHO_BIN_DIR. A validated config.json must exist before service installation:

Linux (systemd user unit)

# Install or update the user service
deploy/member/install.sh --config ~/.config/echo/config.json

# Uninstall the service (retains binaries, state, and credentials)
deploy/member/install.sh --uninstall

macOS (launchd agent)

# Install or update the LaunchAgent
deploy/member/install.sh --config ~/Library/Application\ Support/echo/config.json

# Uninstall the LaunchAgent (retains binaries, state, and credentials)
deploy/member/install.sh --uninstall

Windows (Scheduled Task)

# Install or update the Scheduled Task
deploy/member/install.ps1 -ConfigFile "$env:APPDATA\echo\config.json"

# Uninstall the task (retains binaries, state, and credentials)
deploy/member/install.ps1 -Uninstall

Binary update status and release foundation

Foundational security primitives for binary updates are implemented in current source, but no published end-to-end secure automatic updater or update notification service exists yet:

Migration and compatibility

A legacy profiles.json produces a conversion error only when the default config.json is absent; an existing backup file can safely coexist with a new configuration document. Before switching binaries, operators must review their configuration, validate it with ./bin/ecc config validate, and test services. See the command reference, self-hosting guide, and security guide.