#One Session three different chat views

1 messages · Page 1 of 1 (latest)

tribal rivet
#

I‘m using an agent in the main session. Depending on circumstances and tasks we work on, I switch between the ways to communicate with the agent:
• Signal
• openclaw Tui
• openclaw webui
All three communication channels show different chat histories and different information depth for me on the screen. Is there a way the make that identical?

carmine valeBOT
gleaming mesaBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

carmine valeBOT
sharp reefBOT
#

Short answer: not fully, no.

What’s expected today:

  • TUI + WebUI/Control UI are the closest thing to the source of truth, because they read the gateway-backed transcript.
  • Signal is a messaging surface, so it will not mirror everything 1:1, especially richer transcript details like tool cards, system notices, and some long/normalized history rendering.
  • Even TUI vs WebUI can differ a bit:
    • TUI loads the latest 200 messages by default
    • WebUI bounds/truncates chat.history for stability

So if your goal is identical across all three, that’s not really supported yet.

What I’d recommend:

  1. Use TUI or WebUI as the canonical history view
  2. Use Signal as the convenience chat surface
  3. Make sure both UI surfaces are actually on the same session key (main), otherwise they’ll drift for real
#

and I can help narrow down whether it’s session routing vs just UI behavior.

tribal rivet
#

Overview
┌──────────────────────┬─────────────────
│ Item │ Value
├──────────────────────┼─────────
│ OS │ linux 6.12.75+rpt-rpi-2712 (arm64) · node 22.22.2
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ off
│ Channel │ stable (default)
│ Update │ pnpm · up to date · npm latest 2026.4.21
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 61ms · auth token · B██P█ (███.███.███.███) app 2026.4.21 linux 6.12.75+rpt-rpi-2712
│ Gateway self │ B██P█ (███.███.███.███) app 2026.4.21 linux 6.12.75+rpt-rpi-2712
│ Gateway service │ systemd installed · enabled · running (pid 1317, state active)
│ Node service │ systemd not installed
│ Agents │ 6 · no bootstrap files · sessions 17 · default m███ active 4m ago
│ Memory │ 48 files · 231 chunks · sources memory · plugin memory-core · vector ready · fts ready · cache on (375)
│ Plugin compatibility │ none
│ Probes │ skipped (use --deep)
│ Events │ none
│ Tasks │ 0 active · 0 queued · 0 running · 22 issues · audit 2 errors · 261 warn · 523 tracked
│ Heartbeat │ 30m (m███), 30m (f███), 30m (h███), 30m (k███), 30m (o███), 30m (v███)
│ Sessions │ 17 active · default glm-5.1:cloud (175k ctx) · 6 stores
└──────────────────────┴──────

Task maintenance: openclaw tasks maintenance --apply

Security audit
Summary: 1 critical · 2 warn · 1 info
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - ollama/gemma4:31b-cloud (31B) @ agents.list.o███.model (unsafe; sandbox=off; web=[web_search, web_fetch]) Uncontrolled…
Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
WARN Reverse proxy headers are not trusted

sharp reefBOT
#

Your status looks healthy, and you’re already on current stable (2026.4.21), so this is probably expected behavior, not a broken install.

Short version: there is no “make Signal, TUI, and WebUI identical” switch right now.

What’s happening:

  • They can map to the same underlying session
  • But history is not fully synced back to every client
  • TUI/WebUI are the closest to the gateway transcript
  • Signal is just the messaging surface, so it will not show the same depth/tool details as the UI surfaces

Also, TUI and WebUI can still differ a bit:

  • TUI loads a bounded history, default 200
  • WebUI bounds/truncates chat.history for stability

So the practical answer is:

#
  1. Use TUI or WebUI as your canonical history view
  2. Treat Signal as the lightweight chat endpoint
  3. Make sure both UI surfaces are on the same session key (main)
  4. If needed, increase:
    • TUI history: openclaw tui --history-limit <n>
    • WebUI history depth: gateway.webchat.chatHistoryMaxChars

If you want the closest possible setup, I’d use:

  • Signal for quick/mobile messaging
  • WebUI or TUI for the real transcript / debugging / tool visibility

Docs:

#

If you want, I can help you with a best-effort config to make TUI and WebUI feel much closer, even though Signal still won’t be fully identical.

#

Yep, that session list is the useful clue.

You appear to have one real main session for that agent, agent:m███:main, so this does not look like a routing bug. It looks like the same session rendered through three different clients.

So the mismatch is basically:

  • Signal shows delivered chat messages only
  • TUI shows the gateway transcript plus richer live/tool UI
  • WebUI shows gateway chat.history, but with truncation/normalization rules

In other words, same brain, different window.

Best-effort setup to make it closer:

  • Keep TUI on main
    • openclaw tui --session main --history-limit <n>
  • Keep WebUI on that same main session
#
  • Increase gateway.webchat.chatHistoryMaxChars
  • Avoid /new, /reset, or hopping sessions if you want parity

But even then, Signal still won’t become identical to TUI/WebUI. That part is just current product behavior.

Also, the trustedProxies / denyCommands warnings are unrelated to this history mismatch.

So my answer is:

  • Same session: probably yes
  • Identical history rendering across Signal, TUI, WebUI: currently no
  • Closest source of truth: TUI/WebUI, not Signal

If you want, I can sketch a best-effort config + launch command combo for “TUI and WebUI as close as possible.”

#

Yep, the extra rows don’t change the conclusion.

  • agent:f███:* and agent:h███:* are other agents
  • the relevant one for this discussion is still agent:m███:main

So this looks like a current limitation, not a bad setup.

Bottom line: there is no supported way today to make Signal, TUI, and WebUI render one session identically.

You can only get closer by:

  • keeping both UIs on the same session key
  • raising TUI history with --history-limit
  • increasing gateway.webchat.chatHistoryMaxChars

But Signal parity still won’t be exact.

So if you want true cross-surface identical transcript/history rendering, I’d treat that as a feature request and file it here: