Summary
The runtime-events panel appears not to re-scope when you switch sessions in the UI: it keeps rendering the previously selected session's events under the newly selected session's header.
Evidence
Selecting a session whose header read ses_f2bf38da…, the panel showed 46 events (user.message, several agent.tool_use / agent.tool_result, many agent.message, session.status_idle).
Server-side, for that same session id:
GET /v1/sessions/ses_f2bf38da…/events → 0 eventsGET /session/ses_f2bf38da…/message → 0 messages
A different session selected immediately beforehand has exactly 46 events server-side. Additionally, all 46 rows in the panel shared one identical timestamp (11:55:56.785), which looks like a single batch render rather than a live stream.
So the panel was showing another session's events attributed to this one. The chat pane's "No messages yet" was correct — that session genuinely has nothing stored.
Impact
Actively misleading during evaluation: it implies a run happened on a session that never ran, and it attributes one agent's tool calls and output to another.
Caveat
I have not traced this in the UI source, so I am reporting observed behaviour with the evidence above rather than asserting a root cause — the pattern (stale batch, exact count match with the prior selection) is consistent with the events subscription not being re-created on session change, but that is inference.
Observed on main (53bfd20).
Summary
The runtime-events panel appears not to re-scope when you switch sessions in the UI: it keeps rendering the previously selected session's events under the newly selected session's header.
Evidence
Selecting a session whose header read
ses_f2bf38da…, the panel showed 46 events (user.message, severalagent.tool_use/agent.tool_result, manyagent.message,session.status_idle).Server-side, for that same session id:
GET /v1/sessions/ses_f2bf38da…/events→ 0 eventsGET /session/ses_f2bf38da…/message→ 0 messagesA different session selected immediately beforehand has exactly 46 events server-side. Additionally, all 46 rows in the panel shared one identical timestamp (
11:55:56.785), which looks like a single batch render rather than a live stream.So the panel was showing another session's events attributed to this one. The chat pane's "No messages yet" was correct — that session genuinely has nothing stored.
Impact
Actively misleading during evaluation: it implies a run happened on a session that never ran, and it attributes one agent's tool calls and output to another.
Caveat
I have not traced this in the UI source, so I am reporting observed behaviour with the evidence above rather than asserting a root cause — the pattern (stale batch, exact count match with the prior selection) is consistent with the events subscription not being re-created on session change, but that is inference.
Observed on
main(53bfd20).