zeroclaw-labs/zeroclaw · critical · anyhow::Error

Config contains malformed security-critical sections ({secti

Error message

Config contains malformed security-critical sections ({sections}); they were reset to defaults, so the running posture may be weaker than intended. Refusing to serve with a degraded security posture. Repair these sections in {} and restart — run `zeroclaw config migrate` to see the precise error. To boot anyway (e.g. to reach the gateway config editor and repair from there), re-run with `--allow-degraded-security`.

What it means

ZeroClaw refuses to start serving when one or more security-critical config sections failed to parse and were silently reset to their defaults (tracked in the config.degraded_security list). The guard (see the is_empty() early-return in the SOURCE) only fires when that list is non-empty and the caller did not pass allow_degraded. Refusing to serve prevents an accidentally weakened posture (e.g. permissive defaults) from being mistaken for the operator's intended policy.

Source

Thrown at src/main.rs:7777

    }
    ::zeroclaw_log::record!(
        WARN,
        ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Note)
            .with_outcome(::zeroclaw_log::EventOutcome::Unknown),
        "verifiable_intent: vi_verify is not registered as a model-callable tool because no credential chain verifier exists yet (see #9328)"
    );
}

fn gate_security_posture(
    config: &zeroclaw::config::Config,
    allow_degraded: bool,
) -> anyhow::Result<Option<tokio::task::JoinHandle<()>>> {
    if config.degraded_security.is_empty() {
        return Ok(None);
    }
    let sections = config.degraded_security.join(", ");
    if !allow_degraded {
        anyhow::bail!(
            "Config contains malformed security-critical sections ({sections}); \
             they were reset to defaults, so the running posture may be weaker \
             than intended. Refusing to serve with a degraded security posture. \
             Repair these sections in {} and restart — run `zeroclaw config \
             migrate` to see the precise error. To boot anyway (e.g. to reach \
             the gateway config editor and repair from there), re-run with \
             `--allow-degraded-security`.",
            config.config_path.display()
        );
    }
    let config_path = config.config_path.display().to_string();
    let handle = ::zeroclaw_spawn::spawn!(async move {
        let mut ticker = tokio::time::interval(std::time::Duration::from_secs(30));
        loop {
            ticker.tick().await;
            ::zeroclaw_log::record!(
                WARN,
                ::zeroclaw_log::Event::new(module_path!(), ::zeroclaw_log::Action::Note)

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Run `zeroclaw config migrate` to see the precise parse error and which sections are affected
  2. Fix the reported sections in the config file shown in the error message and restart
  3. If the config was hand-edited, validate the section syntax against the current schema (config migrate reports exact positions)
  4. As a last resort to reach the gateway config editor and repair from there, re-run with `--allow-degraded-security`, then fix and restart without the flag

Example fix

# before (config.toml with a malformed security section)
[security]
allow = "not-a-valid-list   # unterminated / wrong type

# after
[security]
allow = ["127.0.0.1"]

# then verify
zeroclaw config migrate   # reports the exact error and fixed shape
Defensive patterns

Strategy: validation

Validate before calling

// Before starting the gateway, inspect the parsed config the same way the guard does:
if !config.degraded_security.is_empty() {
    eprintln!("degraded security sections: {}", config.degraded_security.join(", "));
    // refuse to proceed, or run `zeroclaw config migrate` programmatically for details
    return Ok(());
}

Try / catch

// When orchestrating zeroclaw as a child process, match the distinctive prefix:
let msg = err.to_string();
if msg.starts_with("Config contains malformed security-critical sections") {
    // surface to the operator; do NOT auto-pass --allow-degraded-security without consent
}

Prevention

When it happens

Trigger: Starting the gateway/serving path with a config file where a security-critical section (auth, permissions, sandbox, allowlists, etc.) has a syntax error, unknown keys, or invalid values. The config loader resets those sections to defaults, records their names in degraded_security, and this bail fires on boot unless the process was started with --allow-degraded-security.

Common situations: Hand-editing the TOML config and introducing a typo; upgrading ZeroClaw to a version that changed a security section's schema so the old file no longer parses; merging config changes from another machine; CI environments regenerating configs from stale templates.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors


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