Bug Summary
User messages are being duplicated/repeated in the conversation UI. The same user message appears 3-4 times in a row before the agent responds.
Observed Behavior
- User sends a single message (e.g. "continue", "wtf what is this error again", or "since when was this issue even fixed")
- The message appears multiple times (3-4 duplicates) in the chat transcript
- The harness note also appears duplicated each time
- This creates a very confusing user experience
Example from session
The user's message "wtf what is this error again [Image] can u take note of the trajectory and file an issue..." appeared 3 times in rapid succession with identical harness notes.
Similarly, "continue" appeared 3 times, and the "ultracode yxlyx/lawplain#91..." message appeared 4 times.
Impact
- Confuses users into thinking their message wasn't received
- Wastes context tokens by feeding duplicate messages to the model
- Degrades trust in the harness reliability
Suggested Fix
The harness frontend should deduplicate incoming user messages before rendering them. A simple dedup by message content + timestamp (within a 5-second window) would prevent this. Alternatively, the backend message ingestion endpoint should reject duplicate message submissions within a short window.
Environment
- Model: kimi-k2.6, gpt-5.5
- Session: lawbook/lawplain repo
- harness.trace.jsonl shows null-byte corruption in the JSONL file
Bug Summary
User messages are being duplicated/repeated in the conversation UI. The same user message appears 3-4 times in a row before the agent responds.
Observed Behavior
Example from session
The user's message "wtf what is this error again [Image] can u take note of the trajectory and file an issue..." appeared 3 times in rapid succession with identical harness notes.
Similarly, "continue" appeared 3 times, and the "ultracode yxlyx/lawplain#91..." message appeared 4 times.
Impact
Suggested Fix
The harness frontend should deduplicate incoming user messages before rendering them. A simple dedup by message content + timestamp (within a 5-second window) would prevent this. Alternatively, the backend message ingestion endpoint should reject duplicate message submissions within a short window.
Environment