openclaw - 💡(How to fix) Fix [Bug]: TUI process starts but UI does not render after gateway restart or kill -9 [1 comments, 2 participants]

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

After restarting the gateway via systemctl --user restart openclaw-gateway or killing the TUI process with kill -9, subsequent openclaw tui invocations start the process and consume ~900MB of memory but never render the interactive UI — only plugin loading log lines appear.

Steps to reproduce

1. Run openclaw tui — UI renders normally
2. Restart the gateway: systemctl --user restart openclaw-gateway
3. Run openclaw tui again — no UI is rendered

Alternative repro path:

1. Run openclaw tui — UI renders normally
2. Kill the TUI process: kill -9 <pid>
3. Run openclaw tui again — no UI is rendered

Expected behavior

openclaw tui should render its interactive UI after a gateway restart or process kill, matching the behavior of a fresh terminal session.

Actual behavior

The openclaw-tui process starts, prints plugin loading log lines, then hangs without rendering the TUI. The process remains alive consuming significant resources:

neo  6295  106  11.8  3341640  945792 pts/2  Rl+  14:32  openclaw-tui

Output observed before the hang:

$ openclaw tui
[plugins] [lcm] Plugin loaded (enabled=true, db=~/.openclaw/lcm.db, threshold=0.75)
[plugins] [lcm] Compaction summarization model: (unconfigured)

No UI is rendered after these log lines. Multiple openclaw-tui processes accumulate (each ~900MB), suggesting the UI is stuck during initialization. Running reset in the terminal before openclaw tui sometimes restores functionality but the issue persists across attempts.

OpenClaw version

2026.4.5 (3e72c03)

Operating system

Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2)

Install method

pnpm dev

Model

NOT_ENOUGH_INFO

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

The TUI rendering failure occurs regardless of the active model or provider configuration — the issue is reproducible during plugin loading, before any model interaction takes place.

Logs, screenshots, and evidence

Process confirmation showing the TUI process is alive and consuming resources but not rendering:

$ openclaw tui
[plugins] [lcm] Plugin loaded (enabled=true, db=~/.openclaw/lcm.db, threshold=0.75)
[plugins] [lcm] Compaction summarization model: (unconfigured)
# <hangs here — no UI rendered>

# In a separate terminal:
$ ps aux | grep openclaw-tui
neo  6295  106  11.8  3341640  945792 pts/2  Rl+  14:32  openclaw-tui

Impact and severity

• Affected: Users running openclaw tui on Linux/WSL2 after gateway restarts or process kills
• Severity: High (blocks TUI workflow — requires new terminal session or reset workaround)
• Frequency: Reproducible on every attempt after gateway restart or kill -9
• Consequence: TUI becomes unusable; repeated attempts accumulate zombie-like processes (~900MB each), leading to significant memory consumption

Additional information

• Gateway runs as a systemd user service
• lossless-claw version: 0.5.3
• The issue appears related to terminal state corruption — when the gateway or TUI process is killed ungracefully, the terminal's alternate screen buffer or raw mode state may not be properly restored, preventing subsequent TUI instances from initializing their UI
• Running reset in the terminal provides a partial workaround but is not reliable across all attempts