Summary

Running zeph --tui with [acp] enabled = true (default transport = stdio) causes the TUI to never open. Instead, the ACP stdio server starts, writes the zeph/ready JSON-RPC notification to stdout, and mcpls child process logs flood stderr.

Root Causes

Bug 1 (Critical) — TUI never starts

configured_acp_autostart_transport in src/runner.rs does not check for --tui mode:

fn configured_acp_autostart_transport(config: &Config, cli: &Cli) -> Option<AcpTransport> {
    if config.acp.enabled && !cli_requested_any_acp_mode(cli) {
        Some(config.acp.transport.clone())  // returns Stdio when tui is active
    } else {
        None
    }
}

The caller does return run_configured_acp_autostart(...) immediately after, so TUI initialization is never reached. ACP stdio and TUI are mutually exclusive — both own stdin/stdout.

Bug 2 (Secondary) — MCP child process stderr corrupts TUI rendering

McpClient::connect in crates/zeph-mcp/src/client.rs uses TokioChildProcess::new(cmd) which defaults to Stdio::inherit() for child stderr. In TUI raw mode + alternate screen, any text written to stderr bleeds through and corrupts ratatui rendering.

Reproduction

# .local/config/cloud.toml
[acp]
enabled = true
# transport defaults to "stdio"

zeph --config .local/config/cloud.toml --tui
# Expected: TUI dashboard opens
# Actual: ACP stdio server starts, zeph/ready written to stdout, TUI never opens

Fix

Bug 1 — src/runner.rs

In configured_acp_autostart_transport, guard stdio autostart against TUI mode:

• AcpTransport::Stdio + --tui: warn and return None
• AcpTransport::Both + --tui: downgrade to Http if acp-http feature is enabled, else warn and return None
• AcpTransport::Http + --tui: allow (HTTP is compatible with TUI)

Bug 2 — crates/zeph-mcp/src/client.rs

Thread suppress_stderr: bool through McpClient::connect → connect_entry → McpManager. Use TokioChildProcess::builder(cmd).stderr(Stdio::null()) in TUI mode. Pass cli.tui from build_tool_setup / create_mcp_manager.

Labels

bug, tui