Summary
Show user messages in the TUI immediately after submission, even when the agent is still working and the server queues the message for later processing.
Current behavior
If the user submits a message while the agent is busy, there is currently no visible representation of that queued message until the server later emits the corresponding user-message event.
Problem
This makes it unclear whether the message was accepted and queued successfully. The user has no visible feedback that their next message is waiting behind the current task.
Expected behavior
When the user submits a message while the agent is still working, the TUI should show that message immediately in a pending or queued state.
Once the server acknowledges or emits the real message event, the pending entry should transition cleanly into the normal chat history entry.
Risks
Without a client correlation id in the protocol, reconciling a locally queued message with a later PromptReceived or UserMessageStored event may be ambiguous, especially if the user submits the same text more than once.
There is also a risk of duplicate chat entries if local pending messages are not merged correctly with server-confirmed messages.
Notes
This likely requires client-side tracking of locally submitted-but-not-yet-acknowledged messages, rather than relying only on server events for chat rendering.
Summary
Show user messages in the TUI immediately after submission, even when the agent is still working and the server queues the message for later processing.
Current behavior
If the user submits a message while the agent is busy, there is currently no visible representation of that queued message until the server later emits the corresponding user-message event.
Problem
This makes it unclear whether the message was accepted and queued successfully. The user has no visible feedback that their next message is waiting behind the current task.
Expected behavior
When the user submits a message while the agent is still working, the TUI should show that message immediately in a pending or queued state.
Once the server acknowledges or emits the real message event, the pending entry should transition cleanly into the normal chat history entry.
Risks
Without a client correlation id in the protocol, reconciling a locally queued message with a later
PromptReceivedorUserMessageStoredevent may be ambiguous, especially if the user submits the same text more than once.There is also a risk of duplicate chat entries if local pending messages are not merged correctly with server-confirmed messages.
Notes
This likely requires client-side tracking of locally submitted-but-not-yet-acknowledged messages, rather than relying only on server events for chat rendering.