aaif-goose/goose · error · anyhow::Error

TLS was requested but no TLS backend is enabled. Enable the

Error message

TLS was requested but no TLS backend is enabled. Enable the `rustls-tls` or `native-tls` feature.

What it means

The ACP serve command can expose its axum router over HTTPS, but TLS backends are optional cargo features. When TLS cert/key paths are supplied and the binary was compiled without either the rustls-tls or native-tls feature, the cfg(not(any(...))) block unconditionally bails with this message before any listener is bound.

Source

Thrown at crates/goose-cli/src/cli.rs:1519

            )
            .await?;
            info!("Starting ACP server on https://{}", addr);

            #[cfg(feature = "rustls-tls")]
            axum_server::bind_rustls(addr, tls_setup.config)
                .serve(router.into_make_service_with_connect_info::<SocketAddr>())
                .await?;

            #[cfg(feature = "native-tls")]
            axum_server::bind_openssl(addr, tls_setup.config)
                .serve(router.into_make_service_with_connect_info::<SocketAddr>())
                .await?;
        }

        #[cfg(not(any(feature = "rustls-tls", feature = "native-tls")))]
        {
            let _ = (tls_cert_path, tls_key_path);
            anyhow::bail!(
                "TLS was requested but no TLS backend is enabled. \
                 Enable the `rustls-tls` or `native-tls` feature."
            );
        }
    } else {
        info!("Starting ACP server on http://{}", addr);
        let listener = tokio::net::TcpListener::bind(addr).await?;
        axum::serve(
            listener,
            router.into_make_service_with_connect_info::<SocketAddr>(),
        )
        .await?;
    }

    Ok(())
}

async fn handle_session_subcommand(command: SessionCommand) -> Result<()> {

View on GitHub (pinned to 3810898a74)

Solutions

1. Rebuild goose with a TLS backend: `cargo build --release --features rustls-tls` (or `native-tls`)
2. Run without TLS by omitting the cert/key flags so the plain HTTP listener path is taken
3. Terminate TLS in front of goose with a reverse proxy (nginx/caddy) and keep goose on http
4. If using a distributed binary, switch to a package/build that enables TLS features

Example fix

# before
cargo build --release
goose acp --serve --tls-cert cert.pem --tls-key key.pem   # bails: no TLS backend

# after
cargo build --release --features rustls-tls
goose acp --serve --tls-cert cert.pem --tls-key key.pem

# Verify a TLS feature is compiled in before passing TLS flags
cargo tree -e features -p goose-cli 2>/dev/null | grep -E 'rustls-tls|native-tls' \
  || echo 'no TLS feature enabled: rebuild with --features rustls-tls, or omit --tls-cert/--tls-key'

When it happens

Trigger: Running the ACP server with tls_cert_path/tls_key_path set on a build produced by plain `cargo build` (no `--features rustls-tls` / `--features native-tls`), so only the plain tokio/axum HTTP branch is compiled in.

Common situations: Prebuilt or community binaries shipped without TLS features; building from source with default features; deployment docs that assume HTTPS support the installed binary does not have.

Understand the failure class

• SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

• Failed to fetch OIDC config: ${configResp.status}
• goose configure requires an interactive terminal. If you ins
• OAuth authentication failed for {}: {}
• Failed to create provider for OAuth: {}
• invalid thinking effort

AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/a5815a048e788a37. Report an issue: GitHub.