Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

When running opencode in Warp on macOS with zsh, Warp can remain stuck on a mostly blank terminal screen after OpenCode exits or tears down. The shell appears to have returned, but Warp does not fully recover the terminal presentation state.
This seems to happen when Warp receives Preexec for the command, but does not receive the normal CommandFinished/Precmd lifecycle afterward. In the affected sessions, Warp logs an unexpected end_in_band_command_output marker.

Observed Behavior

• Run opencode in Warp.
• Exit or trigger teardown from OpenCode.
• Warp sometimes remains on a mostly blank screen.
• The terminal appears visually stuck in TUI/alternate-screen state.
• Warp logs a warning similar to:

Received 'end_in_band_command_output' while not expecting to read in-band command output.

Impact

This makes the terminal session feel broken after using OpenCode. Users may need to reset the terminal/session to recover.

Notes

A safe recovery path may be to restore terminal presentation modes when the unexpected in-band output end marker is received:

• exit alternate screen
• unset bracketed paste if enabled
• do not synthesize CommandFinished
• do not mark the command/block complete
• do not assume the shell prompt is ready without a real Precmd
  This would fix the visible stuck-screen state while avoiding risky command lifecycle inference.

To reproduce

This is intermittent, but I can reproduce it by starting OpenCode and exiting shortly afterward.

1. Open Warp on macOS using zsh.
2. Run opencode.
3. Wait a few seconds for the TUI to initialize.
4. Exit OpenCode shortly after startup.
5. Repeat a few times if needed.

Result

Occasionally, Warp remains on a mostly blank alternate-screen-style view instead of returning to the normal block list/prompt view.

Expected behavior

Warp should recover from the TUI teardown and return to the normal block list/prompt view, without leaving the terminal visually stuck.

Logs

Relevant Warp log lines from the affected session:

026-04-29T09:22:10Z [INFO] Starting shell /bin/zsh
2026-04-29T09:22:10Z [INFO] Successfully spawned tty with pid: 26315
2026-04-29T09:22:10Z [INFO] Successfully spawned child zsh process with pid 26315
2026-04-29T09:22:10Z [INFO] Received CommandFinished hook
2026-04-29T09:22:10Z [INFO] Received Precmd hook
2026-04-29T09:22:14Z [INFO] dispatching typed action: warp::editor::view::EditorAction::Enter
2026-04-29T09:22:14Z [WARN] Received 'end_in_band_command_output' while not expecting to read in-band command output.
2026-04-29T09:22:14Z [INFO] Received Preexec hook
After Received Preexec hook, there is no corresponding:
Received CommandFinished hook
Received Precmd hook```

The expected shell lifecycle appears incomplete around the failure. Warp receives `Preexec` for `opencode`, but the normal completion hooks are missing afterward:
```text
Preexec: opencode
# Expected but not observed:
# CommandFinished
# Precmd

Screenshots, videos, and logs

Received 'end_in_band_command_output' while not expecting to read in-band command output.

Operating system (OS)

macOS

Operating system and version

MacOS 26.4.1 (25E253)

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.04.27.15.32.stable_02

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None