tui feature disabled at compile time; rebuild with…

Error message

tui feature disabled at compile time; rebuild with `--features tui` (or use a default-feature build) to enable `openhuman tui`

What it means

The `openhuman tui` (alias `chat`) subcommand resolved to the compile-time stub because the binary was built without the `tui` Cargo feature - it is not in the default feature set and is intentionally not forwarded to the desktop shell. The stub reports the build fact instead of falling through to 'unknown namespace' so the message reads as a build configuration issue rather than a typo, matching the mcp precedent.

Solutions

Rebuild with the feature: `cargo build --features tui` or a default-feature build.
If you do not need the TUI, use the headless CLI path or `openhuman-core serve` instead.
Distributors: document which published builds include the tui feature.

Example fix

# before
cargo build --no-default-features --features flows

# after
cargo build --no-default-features --features "flows,tui"

Defensive patterns

Strategy: validation

Validate before calling

# refuse to script against a TUI-less build
if openhuman tui </dev/null 2>&1 | grep -q 'tui feature disabled at compile time'; then
  echo 'this build has no TUI; rebuild with --features tui' >&2
  exit 1
fi

Prevention

Build with `--features tui` when the terminal UI is part of your workflow.
Script against exit status and the disabled-build message, not against the TUI appearing.
Remember tui is deliberately absent from desktop-shell builds - do not forward it.

When it happens

Trigger: Running `openhuman tui` or `openhuman chat` on a slim build made with --no-default-features or any explicit feature list that omitted tui; running a product or desktop-shell binary where tui is deliberately excluded via INTENTIONALLY_NOT_FORWARDED.

Common situations: A user installs a release binary built from product-features.txt and tries the TUI; a contributor's minimal kernel-profile build for floor work; custom embeddings that never enabled tui.

Related errors

AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/9b0b55578c50a329. Report an issue: GitHub.

Appendix: source

Thrown at src/core/cli.rs:192

            Some("model") => parsed.model = Some(value.to_string()),
            Some("provider") => parsed.provider = Some(value.to_string()),
            _ => unreachable!("launch option target is fixed above"),
        }
        i += 1;
    }

    parsed.args = args[i..].to_vec();
    Ok(parsed)
}

#[cfg(feature = "tui")]
fn run_tui_from_cli(args: &[String]) -> Result<()> {
    crate::tui::run_from_cli(args)
}

#[cfg(not(feature = "tui"))]
fn run_tui_from_cli(_args: &[String]) -> Result<()> {
    anyhow::bail!(
        "tui feature disabled at compile time; rebuild with `--features tui` \
         (or use a default-feature build) to enable `openhuman tui`"
    )
}

/// Pure launch policy for the bare `openhuman` command. Explicit subcommands
/// are never rewritten. Docker and redirected/CI sessions keep the headless
/// CLI behavior; `openhuman tui` remains an explicit override everywhere.
fn should_auto_launch_tui(
    args: &[String],
    stdin_is_terminal: bool,
    stdout_is_terminal: bool,
    host: crate::core::types::HostKind,
    tui_compiled: bool,
) -> bool {
    args.is_empty()
        && stdin_is_terminal
        && stdout_is_terminal

View on GitHub (pinned to 7491200858)