ECC 2.0 Rust Daemon & Store

Relevant source files

The following files were used as context for generating this wiki page:

• ecc2/src/session/daemon.rs
• ecc2/src/session/store.rs
• ecc2/src/session/runtime.rs
• research/ecc2-codebase-analysis.md
• ecc2/src/main.rs

ECC 2.0 utilizes a robust Rust-based infrastructure to manage the lifecycle, state, and persistence of AI coding agent sessions. The core of this system is comprised of a background daemon responsible for session maintenance and a specialized storage layer that handles SQLite persistence within an asynchronous environment.

The system is designed to handle high-concurrency scenarios by offloading blocking database operations to a dedicated thread, while maintaining a strict state machine for session transitions. This ensures that agent sessions remain consistent even across process restarts or failures.

Sources: research/ecc2-codebase-analysis.md:8-13, research/ecc2-codebase-analysis.md:20-25

Architecture and Core Components

The architecture follows a decoupled pattern where the TUI or CLI interacts with a SessionManager, which utilizes a StateStore for data persistence. A background Daemon ensures that inactive or crashed sessions are properly transitioned to failed or stopped states.

Component Overview

Component	Responsibility	Implementation File
Daemon	Monitors session timeouts, recovers from crashes, and manages lifecycle loops.	session/daemon.rs
StateStore	Manages SQLite connections and provides an interface for session persistence.	session/store.rs
DbWriter	A dedicated OS thread for executing SQLite writes to avoid blocking the async runtime.	session/runtime.rs
Runtime	Captures session output and manages the execution environment for agents.	session/runtime.rs

Sources: research/ecc2-codebase-analysis.md:20-25, ecc2/src/session/daemon.rs:1-10

The DbWriter Pattern

To solve the "SQLite from async" bottleneck, ECC 2.0 implements a DbWriter thread. This component listens on an mpsc::unbounded_channel for write requests and sends acknowledgments via oneshot channels.

The diagram shows how async tasks communicate with the synchronous SQLite writer thread.
Sources: research/ecc2-codebase-analysis.md:26-28, ecc2/src/session/runtime.rs

Data Persistence and Store

The StateStore serves as the primary interface for all database operations. It handles the initial setup of the SQLite database, including schema migrations and state transitions.

Session State Machine

The store enforces strict transitions to prevent illegal state changes. For example, a Running session can transition to Completed, Failed, or Stopped, but a Completed session cannot return to Running.

From State	To State	Condition
Pending	Running, Failed, Stopped	Session started or aborted
Running	Idle, Completed, Failed, Stopped	Task progress or termination
Idle	Running, Completed, Stopped	New command or finalization

Sources: research/ecc2-codebase-analysis.md:29-30, ecc2/src/session/store.rs

Output Buffering

ECC 2.0 implements a ring buffer for session output to prevent memory exhaustion while maintaining enough context for the UI.

• Limit: OUTPUT_BUFFER_LIMIT = 1000 lines per session.
• Eviction: Automatic eviction of the oldest lines once the limit is reached.

Sources: research/ecc2-codebase-analysis.md:31-32, ecc2/src/session/runtime.rs

The Daemon Lifecycle

The Daemon runs as a background process or as a task within the main application. Its primary role is "housekeeping"—ensuring that the database accurately reflects the reality of active processes.

Daemon Responsibilities

1. Timeout Monitoring: Identifies sessions that have not reported activity within a configured threshold.
2. Crash Recovery: Transitions sessions from Running to Failed if the underlying agent process is no longer detected.
3. Liveness Handling: Updates timestamps for active sessions to prevent them from being marked as timed out.

This flowchart illustrates the logic loop executed by the ECC 2.0 Daemon to maintain session health.
Sources: ecc2/src/session/daemon.rs:15-45, research/ecc2-codebase-analysis.md:58-61

Key Data Structures

SessionMetrics

Tracks resource usage and performance data for every agent session.
Sources: research/ecc2-codebase-analysis.md:54-57

pub struct SessionMetrics {
    pub tokens: u32,
    pub cost: f64,
    pub duration_ms: u64,
    pub tool_calls: u32,
    pub files_changed: u32,
}

Risk Scoring (Observability)

Integrated into the store and runtime is a 4-axis risk analysis for tool calls:

• Base Tool Risk: Inherent danger of the command (e.g., rm vs ls).
• File Sensitivity: Access to .env or system files.
• Blast Radius: Number of files or directories affected.
• Irreversibility: Whether the action can be undone via Git.

Sources: research/ecc2-codebase-analysis.md:33-36

Summary of Implementation Gaps

As of the current codebase analysis, certain features within the Daemon and Store are noted as stubs or areas for improvement:

• Health Reporting: The daemon lacks a health endpoint or signal handling for graceful shutdowns.
• Aggregate Metrics: While individual sessions are tracked, the store does not yet provide cross-session cost or performance aggregation.
• Multi-Agent Support: The system is currently optimized for "claude", with other agents receiving limited support in the manager layer.

Sources: research/ecc2-codebase-analysis.md:43-61

The ECC 2.0 Rust Daemon and Store provide the essential stability layer for agentic coding. By utilizing the DbWriter pattern for SQLite and a robust state machine for session management, the system ensures that AI workflows are persistent, observable, and recoverable.