TUI v3 becomes unresponsive to keyboard input while BBS task is running

[jesslink1]

Bug: TUI v3 window stops accepting keyboard input while BBS task is running

Summary

A TUI v3 window can become effectively frozen/unresponsive to keyboard input while a BBS-backed task is running. The background BBS service continues to run and listen on its port, so the issue appears to be in the TUI/input/event-loop side rather than the BBS process itself being dead.

Observed behavior

• The TUI v3 window remains open, but typing in the terminal no longer enters text.
• It feels like the TUI is stuck or the terminal input is captured/lost.
• The related BBS task should not be interrupted, so killing the TUI process is unsafe.
• BBS continues to be alive and serving connections.

Environment / facts captured

• OS: Windows
• Terminal: Windows Terminal / PowerShell
• Repository: https://github.com/lsdefine/GenericAgent
• Branch observed locally: main
• Last local commit: 1265568 feat(worldline): checkpoint-tree rewind for tui_v2 (feat(worldline): checkpoint-tree rewind for tui_v2 #625)
• TUI v3 processes observed:
  • PID 35316: C:\Python313\python.exe .\tui_v3.py
  • PID 39528: C:\Python313\python.exe .\tui_v3.py
• BBS process observed:
  • PID 20200: C:\Python313\python.exe D:\test\GenericAgent\assets\agent_bbs.py --cwd D:\test\GenericAgent\temp\projects\i4ToolsHm-06c2e449\hive_i4ToolsHm --port 8357 --key ...
• Port check showed BBS still active:
  • 0.0.0.0:8357 LISTEN PID 20200
  • established localhost connections on port 8357

Expected behavior

The TUI should remain responsive to keyboard input while background/BBS tasks are running, or it should clearly show that input is temporarily disabled and provide a safe recovery path that does not interrupt the task.

Actual behavior

The TUI window appears stuck and stops accepting text input, while the BBS backend remains alive.

Possible causes to investigate

• TUI v3 event loop blocked by synchronous polling/tool/task operation.
• Terminal raw input/alternate-screen state not restored or focus/input mode lost.
• BBS/task polling performed on the UI thread.
• Keyboard input handler starved while background task is active.

Safety note

Killing the TUI process may interrupt task orchestration/state, so a non-destructive recovery mechanism would be helpful, e.g. watchdog, reconnect, or input loop reset.