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
- Run `zeroclaw config migrate` to see the precise parse error and which sections are affected
- Fix the reported sections in the config file shown in the error message and restart
- If the config was hand-edited, validate the section syntax against the current schema (config migrate reports exact positions)
- 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
- Validate configs with `zeroclaw config migrate` in CI before deploying
- Treat any degraded_security entry as a deploy blocker in health checks
- Never leave --allow-degraded-security in long-lived service definitions
- After schema-changing upgrades, run config migrate before restart
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.
- Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.
Related errors
- matrix: `homeserver` is required
- transcription.max_audio_bytes must be greater than zero
- Transcription is enabled but no transcription provider regis
- Transcription is enabled but no transcription provider regis
- Edge TTS binary_path must be a bare command name without pat
AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23).
Data as JSON: /api/errors/1c9c67410a2d5e80.
Report an issue: GitHub.