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
- Bind to a loopback address (e.g. `--listen 127.0.0.1:<port>`) if only local access is needed.
- Remove `--insecure-no-auth` and supply an explicit token via `--auth-token <token>` or the `CODEWHALE_APP_SERVER_TOKEN` env var.
- 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
- Never combine --insecure-no-auth with a 0.0.0.0 or LAN bind in scripts/deployment templates.
- Prefer explicit --auth-token even for local use so the same launch line works everywhere.
- Lint startup scripts for the insecure-no-auth flag.
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.
- Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.
Related errors
- Managing API keys needs an interactive login. Run…
- refusing non-loopback app-server bind without explicit auth…
- --set is not supported by auth commands; use a saved config
- --bridge is required in --non-interactive mode.
- Codewhale account API base URL must not contain credentials
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)