fix: Render conversation history in the UI

[sjathin]

Summary of PR

• ConversationRunner.replay_events() — new method that iterates persisted events and renders them through the visualizer. User messages get special handling via render_user_message() since on_event()
  intentionally skips them (they're normally rendered separately by the UI layer).
• OpenHandsApp._replay_conversation_history() — called during _initialize_main_ui() when --resume is used. Eagerly creates the runner and replays events.
• ConversationSwitchController._prepare_switch() — now calls runner.replay_events() after get_or_create() so switching via the history panel also shows prior conversation history.

Demo Screenshots/Videos

Screen.Recording.2026-03-22.at.18.57.01.mov

Change Type

• Bug fix
• New feature
• Breaking change
• Refactor
• Other (dependency update, docs, typo fixes, etc.)

Checklist

• I have read and reviewed the code and I understand what the code is doing.
• I have tested the code to the best of my ability and ensured it works as expected.

Fixes

Resolves #287

Release Notes

• Include this change in the Release Notes.

Renders conversation history in the UI

[enyst]

It seems this only shows user messages. I think conversation history has many other events, since it's the history of agent's run.

[sjathin]

The code handles all event types — the replay_events method sends every non-user event through on_event, which renders ActionEvent, ObservationEvent, MessageEvent (assistant), ConversationErrorEvent, FinishAction, ThinkAction, etc.

See

Screen.Recording.2026-03-22.at.18.57.01.mov

[enyst]

Thank you for looking into this!

I left a few comments inline. Sorry, the PR doesn't currently render conversation history, which can have many more agent events.

The video you posted shows an error only. If you add an LLM and run the agent, for real, it will not render conversation history, I think?

I will mark this PR as draft, please feel free to set it ready when it's ready for review.

[sjathin]

@enyst

Thanks for reviewing the PR.

Marking it as Ready for review again. I have addressed the comments above:

PR doesn't currently render conversation history

The code handles all event types — the replay_events method sends every non-user event through on_event, which renders ActionEvent, ObservationEvent, MessageEvent (assistant), ConversationErrorEvent, FinishAction, ThinkAction, etc.

attempting to go through ALL events in history has O(n) complexity

Added a cap to replay_events() so we only replay the tail end of the history.

[sjathin]

@enyst

Looked into the PR #562 there has been no updates on it since the last month. Could we prioritize this PR?

[cbagwell]

I am interested in this feature so I gave it a test. I tested this PR because I can wrap my head around what the 3 file changes are doing while the other PR modifies 24 files. I also thought it would help reviews if broken into 3 incremental features:

1. Replay X newest events on resume.
2. Add a way to click and load X more older events incrementally.
3. Implement an infinite style scroll to replace clicking.

This PR does 1 and works great for me. A review comment is some tests might be good. Maybe a snapshot test showing the restored text? Not sure exactly.

I had an agent rebase this patch to latest main and then create a draft patch for 2. It needs closer review and more testing (for example, loading only works with mouse I think). https://github.com/cbagwell/OpenHands-CLI/tree/feat/history-on-restore

Feel free to incorporate that patch into this PR or if this one is merged as-is I can create a follow up PR.

[cbagwell]

As a data point about the limit of 50: I have an older machine where the SDK itself takes 10 seconds to load on its own before openhands loads. So it's on the slow side. I then made the cutoff limit very high to basically disable it and I loaded a conversation with 1K events. I didn't notice all that much of a lag or memory usage. It did take maybe 4 seconds to load the full conversation which I didn't feel was bad. Also, it did a better job because it also seemed to have restored the fact that the planner pane was last open... whereas when cutoff was hit, that wasn't done.

I wonder what a proper cutoff value is and if 50 is to low?