Hmbown/CodeWhale · critical · anyhow::Error

refusing unauthenticated app-server bind on non-loopback…

Error message

refusing unauthenticated app-server bind on non-loopback address

What it means

The app-server refuses to start with HTTP authentication disabled (`--insecure-no-auth`) while binding to a non-loopback address. Disabling auth exposes the server's full control API (threads, prompts, attachments) without any token, so it is only tolerated on 127.0.0.1/::1. This is a deliberate fail-loud guard against an unsafe deployment configuration.

Solutions

  1. Bind to a loopback address (e.g. `--listen 127.0.0.1:<port>`) if only local access is needed.
  2. Remove `--insecure-no-auth` and supply an explicit token via `--auth-token <token>` or the `CODEWHALE_APP_SERVER_TOKEN` env var.
  3. If remote access truly must be unauthenticated (never recommended), tunnel it through SSH/localhost forwarding instead of binding non-loopback.

Example fix

// before
app-server --insecure-no-auth --listen 0.0.0.0:3927
// after
app-server --auth-token "$MY_TOKEN" --listen 0.0.0.0:3927
Defensive patterns

Strategy: validation

Validate before calling

// Rust-style pre-check before launching
fn ensure_safe_no_auth(listen: std::net::IpAddr) -> Result<(), String> {
    if listen.is_loopback() { Ok(()) } else { Err(format!("{} is non-loopback; --insecure-no-auth is not allowed", listen)) }
}

Prevention

When it happens

Trigger: Launching the app-server with `--insecure-no-auth` (or the equivalent options.insecure_no_auth flag) while `options.listen` resolves to a non-loopback IP such as 0.0.0.0 or an external interface address.

Common situations: Developers trying to expose the app-server to a container sibling, LAN device, or Docker port map who pass `--insecure-no-auth` together with `--listen 0.0.0.0:<port>` instead of configuring a token.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors


AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/7152f206f3980652. Report an issue: GitHub.

Appendix: source

Thrown at crates/app-server/src/lib.rs:882

        runtime_bridge: Arc::new(Mutex::new(None)),
        runtime_thread_map: Arc::new(Mutex::new(HashMap::new())),
        stdio_thread_hints: Arc::new(Mutex::new(HashMap::new())),
        in_flight_turns: Arc::new(Mutex::new(HashMap::new())),
    })
}

fn resolve_auth_token(options: &AppServerOptions) -> Result<Option<String>> {
    let configured = options.auth_token.as_ref().map(|token| token.trim());
    if let Some(token) = configured
        && token.is_empty()
    {
        bail!("app-server auth token cannot be empty");
    }
    let has_explicit_token = configured.is_some();

    if options.insecure_no_auth {
        if !options.listen.ip().is_loopback() {
            bail!("refusing unauthenticated app-server bind on non-loopback address");
        }
        eprintln!("warning: app-server HTTP auth disabled by --insecure-no-auth");
        return Ok(None);
    }

    if !has_explicit_token && !options.listen.ip().is_loopback() {
        bail!(
            "refusing non-loopback app-server bind without explicit auth token; pass --auth-token or set CODEWHALE_APP_SERVER_TOKEN"
        );
    }

    let token = configured
        .map(str::to_string)
        .unwrap_or_else(|| format!("cwapp_{}", Uuid::new_v4().simple()));
    for line in app_server_auth_status_lines(has_explicit_token) {
        eprintln!("{line}");
    }
    Ok(Some(token))

View on GitHub (pinned to 73e0f67d83)