Skip to content

TUI runtime supervisor resilience + memory op visibility parity #3574

@njfio

Description

@njfio

Problem statement

Tau TUI still exits hard when the interactive runtime child exits non-zero (for example provider invalid response / empty last message paths), and operators lose control of the session. In addition, memory operation visibility is still incomplete: TUI and web surfaces do not consistently expose turn-time memory reads/writes/deletes in a way that confirms the memory system is active.

Acceptance criteria

  1. TUI resilience on child failure
  • In app-renderer mode, non-zero interactive runtime child exits do not terminate Tau TUI immediately.
  • TUI renders a clear runtime-failed status in UI panes.
  • Operator can recover from UI via /restart local command without relaunching the whole TUI process.
  1. Provider failure normalization behavior
  • Failure signatures such as "codex cli failed ... no last agent message" are treated as turn/runtime failure status lines and remain visible in Assistant/Events panes.
  • Error is explicit and observable; no silent fallback semantics.
  1. Memory operation visibility parity
  • Turn-time memory tool operations include read visibility (memory.read) in addition to existing write/delete visibility where available.
  • /memory output in TUI includes recent memory activity lines so operator can verify read/write/delete activity after turns.
  1. Tests
  • Add/extend tests for local /restart command parsing and handling.
  • Add regression coverage for memory read event mapping + /memory rendering path.

Non-goals

  • Full TUI visual redesign.
  • Changing provider API contracts.
  • Background memory distill algorithm redesign.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions