zeroclaw-labs/zeroclaw · error

lucid command failed: {stderr}

Error message

lucid command failed: {stderr}

What it means

The lucid subprocess ran to completion but exited non-zero; its stderr is captured and surfaced verbatim in the error. This is lucid's own failure (authentication, bad invocation, missing data) rather than a timeout or transport problem on the zeroclaw side — the child answered, it just failed.

Source

Thrown at crates/zeroclaw-memory/src/lucid.rs:312

                        })),
                    "lucid command timed out"
                );
                if let Some(cleanup_error) = cleanup_error {
                    anyhow::bail!(
                        "lucid command timed out after {}ms; failed to terminate and reap child: {cleanup_error}",
                        timeout_window.as_millis()
                    );
                }
                anyhow::bail!(
                    "lucid command timed out after {}ms",
                    timeout_window.as_millis()
                );
            }
        };

        if !status.success() {
            let stderr = String::from_utf8_lossy(&stderr_bytes);
            anyhow::bail!("lucid command failed: {stderr}");
        }

        Ok(String::from_utf8_lossy(&stdout_bytes).to_string())
    }

    async fn run_lucid_command(
        &self,
        args: &[String],
        timeout_window: Duration,
    ) -> anyhow::Result<String> {
        Self::run_lucid_command_raw(&self.lucid_cmd, args, timeout_window).await
    }

    fn build_store_args(&self, key: &str, content: &str, category: &MemoryCategory) -> Vec<String> {
        let payload = format!("{key}: {content}");
        vec![
            "store".to_string(),
            payload,

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Read the stderr text embedded in the message — it is lucid's own error and usually names the fix.
2. Reproduce by running the same lucid command manually with the same user/env.
3. Re-authenticate lucid or roll back/pin the lucid CLI version to one matching this integration.

Example fix

# diagnose: run the failing command manually
$ lucid --version
$ lucid search "test query"
# re-auth if stderr mentions credentials
$ lucid login

match run_lucid_command(&args).await {
    Ok(stdout) => Ok(parse(stdout)),
    Err(e) => {
        let msg = e.to_string();
        if let Some(stderr) = msg.strip_prefix("lucid command failed: ") {
            // classify: auth failures are operator-actionable and not retryable
            if stderr.contains("auth") || stderr.contains("credential") {
                return Err(e.context("lucid needs re-authentication"));
            }
        }
        Err(e)
    }
}

When it happens

Trigger: wait_for_lucid_child checks !status.success() after the child exits: lucid CLI not authenticated or its credentials expired, an unsupported lucid version or subcommand, or lucid-side errors such as a missing remote dataset — the reason is in stderr.

Common situations: Expired lucid API token; lucid binary updated with breaking CLI changes; environment variables for lucid missing in the service context; remote workspace deleted on the lucid side.

Related errors

• edge-tts failed (exit {}): {}
• lucid command timed out after {}ms; failed to terminate and
• lucid command timed out after {}ms
• Edge TTS subprocess timed out
• update --check failed: {}

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/5bea730f5bd16b6a. Report an issue: GitHub.