[PR #160] [MERGED] Fix: TUI display corruption when launched via default command #171

New issue

Closed

opened 2026-02-27 10:22:30 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 10:22:30 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/mikeyobrien/ralph-orchestrator/pull/160
Author: @cockroach-eater
Created: 2/6/2026
Status: ✅ Merged
Merged: 2/6/2026
Merged by: @mikeyobrien

Base: main ← Head: fix-tui-at-run-without-args

📝 Commits (1)

123cc6f fix tui at run without args

📊 Changes

2 files changed (+2 additions, -0 deletions)

View changed files

📝 crates/ralph-cli/src/main.rs (+1 -0)
📝 crates/ralph-tui/src/app.rs (+1 -0)

📄 Description

Bug

When launching Ralph without a subcommand (ralph instead of ralph run), the TUI renders with severe visual corruption - log output bleeds into the terminal display, making it unusable until the window is resized.

Root Cause

The tui_enabled flag in main.rs determines whether tracing output is redirected from stdout to a log file. This flag only matched Some(Commands::Run(...)) and Some(Commands::Resume(...)), but the default command (no subcommand) produces cli.command = None - which fell through to _ => false.

The result: TUI was started by the None arm (which creates RunArgs with no_tui: false), but the tracing subscriber was configured to write to stdout instead of a file. Every tracing::info!() call wrote directly to the terminal, corrupting the alternate screen buffer that ratatui manages.

Steps to Reproduce

Run ralph (no subcommand) in a project with a valid ralph.yml
Observe the TUI - log lines render over the TUI content
Resize the terminal window - display partially recovers but breaks again on next iteration

Expected Behavior

TUI renders cleanly with header, content pane, and footer. Log output goes to .ralph/diagnostics/logs/.

Actual Behavior

Raw tracing log lines (2026-... INFO ralph_core::event_loop: ...) render directly on the terminal, overlapping and corrupting the TUI layout. Resizing the window temporarily fixes the display because ratatui forces a full repaint, but the next log line corrupts it again.

Fix

crates/ralph-cli/src/main.rs - Add None => true to the tui_enabled match so the default command (no subcommand) correctly redirects logs to a file:

let tui_enabled = match &cli.command {
    Some(Commands::Run(args)) => !args.no_tui && !args.autonomous,
    Some(Commands::Resume(args)) => !args.no_tui && !args.autonomous,
    None => true, // Default command runs with TUI enabled
    _ => false,
};

crates/ralph-tui/src/app.rs - Add terminal.clear() after terminal initialization. This is a ratatui best practice that ensures the first frame renders correctly regardless of the alternate screen's initial state.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/mikeyobrien/ralph-orchestrator/pull/160 **Author:** [@cockroach-eater](https://github.com/cockroach-eater) **Created:** 2/6/2026 **Status:** ✅ Merged **Merged:** 2/6/2026 **Merged by:** [@mikeyobrien](https://github.com/mikeyobrien) **Base:** `main` ← **Head:** `fix-tui-at-run-without-args` --- ### 📝 Commits (1) - [`123cc6f`](https://github.com/mikeyobrien/ralph-orchestrator/commit/123cc6f5e6be3cf20aaec092a083fa36d09f58b1) fix tui at run without args ### 📊 Changes **2 files changed** (+2 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `crates/ralph-cli/src/main.rs` (+1 -0) 📝 `crates/ralph-tui/src/app.rs` (+1 -0) </details> ### 📄 Description ### Bug When launching Ralph without a subcommand (`ralph` instead of `ralph run`), the TUI renders with severe visual corruption - log output bleeds into the terminal display, making it unusable until the window is resized. ### Root Cause The `tui_enabled` flag in `main.rs` determines whether tracing output is redirected from stdout to a log file. This flag only matched `Some(Commands::Run(...))` and `Some(Commands::Resume(...))`, but the default command (no subcommand) produces `cli.command = None` - which fell through to `_ => false`. The result: TUI was started by the `None` arm (which creates `RunArgs` with `no_tui: false`), but the tracing subscriber was configured to write to stdout instead of a file. Every `tracing::info!()` call wrote directly to the terminal, corrupting the alternate screen buffer that ratatui manages. ### Steps to Reproduce 1. Run `ralph` (no subcommand) in a project with a valid `ralph.yml` 2. Observe the TUI - log lines render over the TUI content 3. Resize the terminal window - display partially recovers but breaks again on next iteration ### Expected Behavior TUI renders cleanly with header, content pane, and footer. Log output goes to `.ralph/diagnostics/logs/`. ### Actual Behavior Raw tracing log lines (`2026-... INFO ralph_core::event_loop: ...`) render directly on the terminal, overlapping and corrupting the TUI layout. Resizing the window temporarily fixes the display because ratatui forces a full repaint, but the next log line corrupts it again. ### Fix **`crates/ralph-cli/src/main.rs`** - Add `None => true` to the `tui_enabled` match so the default command (no subcommand) correctly redirects logs to a file: ```rust let tui_enabled = match &cli.command { Some(Commands::Run(args)) => !args.no_tui && !args.autonomous, Some(Commands::Resume(args)) => !args.no_tui && !args.autonomous, None => true, // Default command runs with TUI enabled _ => false, }; ``` **`crates/ralph-tui/src/app.rs`** - Add `terminal.clear()` after terminal initialization. This is a ratatui best practice that ensures the first frame renders correctly regardless of the alternate screen's initial state. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>