Fix TUI zero state after shell bootstrap

[warp-dev-github-integration]

Description

Fixes TuiTranscriptView::is_empty() so the Warp Agent zero state remains visible after shell bootstrap. Pre-user shell bootstrap stages no longer count as transcript content, and terminal blocks only count when they have displayed command/output rows.

@kevinyang372 Please review the transcript emptiness boundary and the render regression for zero-height bootstrap blocks.

Linked Issue

Fixes CODE-1887

• The linked issue is ready for implementation.
• Verification evidence is included below.

Testing

• Manually built and ran warp-tui-dev under tmux at 120x40 with process-scoped TUI authentication.
• Confirmed Warp Agent, dev build, project context, and MCP status render after shell bootstrap.
• Submitted Reply with OK. and confirmed the zero state is replaced by the first conversation.
• env -u WARP_API_KEY cargo +1.92.0 nextest run -p warp_tui — 403 passed.
• env -u WARP_API_KEY cargo +1.92.0 nextest run -p warpui_core — 311 passed, 7 skipped.
• ./script/format
• All three clippy commands from ./script/presubmit with -D warnings.

Before — post-bootstrap zero state missing

(rows 1-28 blank)
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘
← for conversations        auto (genius) /workspace/warp-code-1887

After — zero state rendered after bootstrap

Warp Agent
dev build

/workspace/warp-code-1887
✓ AGENTS.md loaded
✓ 20 skills discovered

MCP
~/.config/warp-terminal-dev/cli/.mcp.json
Not configured · /mcp

Behavior — first prompt dismisses zero state

> Reply with OK.

OK.

∷ 1s • 1.6 credits

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Fixed the Warp Agent welcome screen not appearing after shell startup in the TUI.

Conversation: https://staging.warp.dev/conversation/9e280d03-a296-47ca-a35d-c6ee847b584f
Run: https://oz.staging.warp.dev/runs/019f7f5b-f34c-7809-bbd9-160efaae094a

Co-Authored-By: Oz oz-agent@warp.dev

This PR was generated with Oz.

[kevinyang372]

The content-row refinement makes sense, and the parent render branch guarantees that the zero state and transcript cannot be painted simultaneously (if is_empty { zero state } else { transcript }). However, I don't think this preserves the intended interactive-bootstrap flow.

The new predicate only counts terminal blocks when:

block.is_restored() || block.bootstrap_stage().is_done()

BootstrapStage::is_done() only covers PostBootstrapPrecmd, so a visible, unfinished ScriptExecution block is ignored by is_empty(). Input routing is computed independently and can still select the PTY for a visible startup interaction. This means something like an Oh My Zsh update prompt could accept keystrokes while the zero state is displayed instead of the interactive bootstrap block.

The desired behavior seems to be:

1. A visible, unfinished bootstrap block renders and owns PTY input.
2. Once it finishes, it stops suppressing zero state.
3. The first normal post-bootstrap command dismisses zero state again.

A lifecycle condition consistent with that would be:

block.is_restored() || block.bootstrap_stage().is_done() || !block.finished()

The existing test covers only a finished bootstrap block with zero displayed content rows. Could we add an integrated transition test that asserts:

• running visible startup block: transcript nonempty, prompt visible, zero state absent, input target is PTY;
• after finishing that block: transcript empty and zero state visible;
• after the first post-bootstrap shell command: zero state dismissed?

One small caveat: because emptiness now requires displayed rows, an accepted shell command may leave zero state visible for a transient frame until its first command/output row appears.

[warp-dev-github-integration]

Thanks for the thorough review, @kevinyang372!

Changes made:

should_render_terminal_block(block, block_list)

A visible, unfinished bootstrap block (e.g. an Oh My Zsh update prompt running ScriptExecution) now suppresses the zero state while it's running and owns PTY input. Once finished, it stops satisfying the predicate and the zero state becomes visible — until the first normal PostBootstrapPrecmd command comes in with content.

2. Integrated transition test — Added zero_state_transitions_through_bootstrap_lifecycle covering the three phases you described:

   • Phase 1: unfinished ScriptExecution block with visible output → is_empty() = false (zero state hidden)
   • Phase 3: first PostBootstrapPrecmd command with visible output → is_empty() = false (zero state dismissed)

3. Merge conflicts — Rebased on current master, keeping both the TuiInputTarget import added by master and the block_content_rows/should_render_terminal_block imports from this PR.

One small caveat: because emptiness now requires displayed rows, an accepted shell command may leave zero state visible for a transient frame until its first command/output row appears.

Acknowledged — this is an inherent property of the content-row guard and is acceptable for a single-frame flicker that resolves immediately once the grid has content.

[oz-for-oss]

@kevinyang372

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR tightens TuiTranscriptView::is_empty() so zero-height shell bootstrap blocks no longer suppress the TUI zero state, exposes the existing terminal content-row helper to sibling TUI tests/code, and adds regression coverage for the bootstrap lifecycle and first-command transition.

Concerns

• No blocking correctness, security, or spec-alignment concerns found in the annotated diff.
• No approved or repository spec context was provided for this PR.
• The PR includes TUI transcript captures in the description, which satisfy the repo guidance for visual evidence on headless TUI behavior changes.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz