What causes "daemon did not return an agent-readiness response" in astrid-runtime/astrid?

Restart the daemon to match the CLI's protocol version

daemon did not return an agent-readiness response

Error message

daemon did not return an agent-readiness response

What it means

agent_readiness expects KernelResponse::AgentReadiness or KernelResponse::Error. Any other response variant falls into the catch-all arm and raises this error. The daemon answered within the deadline but with a type that cannot carry readiness data.

Solutions

Restart the daemon to match the CLI's protocol version
Rebuild CLI and daemon together from the same commit
Verify the daemon supports GetAgentReadiness (check its request dispatcher)
Include the received variant name in the error message for easier diagnosis

Example fix

// before
_ => Err(anyhow::anyhow!("daemon did not return an agent-readiness response")),
// after
other => Err(anyhow::anyhow!(
    "daemon did not return an agent-readiness response (got {other:?}) — CLI/daemon version mismatch?"
)),

Defensive patterns

Strategy: type-guard

Type guard

fn as_agent_readiness(resp: &KernelResponse) -> Option<&astrid_core::kernel_api::AgentLoopReadiness> {
    match resp {
        KernelResponse::AgentReadiness(r) => Some(r),
        _ => None,
    }
}

Try / catch

match agent_readiness().await {
    Err(e) if e.to_string().contains("agent-readiness response") => {
        // CLI/daemon version skew: restart daemon and retry
        restart_daemon().await?;
        agent_readiness().await?;
    }
    other => other?,
}

Prevention

Always rebuild and restart daemon together with the CLI
Add a version/feature handshake before issuing new request types
Log the unexpected variant in the catch-all error arm

When it happens

Trigger: A daemon responding to GetAgentReadiness with a variant like Status or Pong — usually a CLI/daemon version skew where the old daemon doesn't know GetAgentReadiness and replies with a generic acknowledgment.

Common situations: Mixed-version deployments after upgrading the CLI without restarting/rebuilding the daemon; protocol evolution adding new request types.

Related errors

AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/9fb96339ca996945. Report an issue: GitHub.

Appendix: source

Thrown at crates/astrid-cli/src/commands/doctor.rs:271

async fn agent_readiness() -> Result<astrid_core::kernel_api::AgentLoopReadiness> {
    let mut client = tokio::time::timeout(
        Duration::from_secs(5),
        crate::socket_client::connect_kernel_for_workspace(None),
    )
    .await
    .map_err(|_| anyhow::anyhow!("connection timed out after 5s"))??;
    match tokio::time::timeout(
        Duration::from_secs(5),
        client.request(KernelRequest::GetAgentReadiness),
    )
    .await
    .map_err(|_| anyhow::anyhow!("daemon response timed out after 5s"))??
    {
        KernelResponse::AgentReadiness(readiness) => Ok(readiness),
        KernelResponse::Error(msg) => {
            Err(anyhow::anyhow!("daemon rejected readiness query: {msg}"))
        },
        _ => Err(anyhow::anyhow!(
            "daemon did not return an agent-readiness response"
        )),
    }
}

async fn projection_name_diagnostic(
    policy: ProjectionNamePolicyPreset,
) -> Result<ProjectionNameDiagnostic> {
    let mut client = tokio::time::timeout(
        Duration::from_secs(5),
        crate::socket_client::connect_kernel_for_workspace(None),
    )
    .await
    .map_err(|_| anyhow::anyhow!("connection timed out after 5s"))??;
    tokio::time::timeout(
        Duration::from_secs(30),
        client.projection_name_diagnostic(policy),
    )

View on GitHub (pinned to affd8760f4)