tui feature disabled at compile time; rebuild with `--featur

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

This binary was compiled without the `tui` cargo feature, so `run_tui_from_cli` is the #[cfg(not(feature = "tui"))] stub that reports the build fact instead of pretending the subcommand is unknown. It is a compile-time gate, not a runtime setting: no config, env var, or flag can enable the TUI in this binary. Note the message's '(or use a default-feature build)' parenthetical — in this repo `default` does NOT include `tui` (Cargo.toml lists media/skills/flows/mcp/channels/medulla/http-server/scheduler-gate/file-logging), so the reliable fix is an explicit `--features tui` rebuild; the desktop shell intentionally does not forward this gate.

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 a221052e0d)

Solutions

Rebuild with the gate enabled: `cargo build --bin openhuman-core --features tui`
Or use a binary you know was built with `tui` in its feature list (check with `cargo tree -i ratatui` against that build)
Or stay headless: `openhuman run` / namespace commands are always compiled and need no gate

Example fix

# before
openhuman tui   # -> tui feature disabled at compile time
# after
cargo build --manifest-path Cargo.toml --bin openhuman-core --features tui
./target/debug/openhuman-core tui

Defensive patterns

Strategy: validation

Validate before calling

# bash: fail fast if this binary lacks the tui gate before relying on it
if ! cargo tree --manifest-path Cargo.toml -i ratatui --features tui >/dev/null 2>&1; then
  echo 'build does not enable tui; rebuild with --features tui' >&2; exit 1
fi
# at runtime, probe the stub's distinctive stderr marker in a subprocess:
if openhuman tui </dev/null 2>&1 | grep -q 'feature disabled at compile time'; then
  echo 'this binary has no TUI; falling back to headless CLI' >&2
fi

Try / catch

out=$(openhuman tui 2>&1 >/dev/null); case "$out" in *'disabled at compile time'*) echo 'build lacks --features tui; using headless CLI instead' >&2; openhuman run;; *) echo "$out" >&2; exit 1;; esac

Prevention

Note that the repo's default feature list does NOT include tui — always pass --features tui explicitly when building for interactive use
The desktop shell intentionally never forwards this gate; do not expect the TUI there
Pin and document the exact cargo feature list for binaries you distribute

When it happens

Trigger: Running `openhuman tui` (or the alias `openhuman chat`) on a binary built with `--no-default-features`, a slim/kernel feature list, or the contrib `default` set — all of which omit `tui`; a desktop-shell build, which deliberately never gets the feature.

Common situations: Interactive debugging against a slim build optimized for compile speed; CI-built binaries; scripts assuming the TUI exists everywhere; stale binaries from an older feature configuration.

Related errors

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