Jev Chat Jarvis Bug Review: Conversation History Can Silently Lose New Messages

Jev Chat Jarvis is a rapidly growing Android project that watches conversations visible inside apps such as WeChat, QQ, X, and Feishu, analyzes the exchange, and generates suggested responses. The project was created only recently and has already accumulated thousands of stars and hundreds of forks, making it one of the faster moving new repositories on GitHub.

Its architecture depends heavily on conversational context. Jev Chat Jarvis can optionally save previous messages for individual contacts, then include recent history when analyzing the current conversation. That makes the accuracy of its history system unusually consequential. During a review of that implementation, we found a case where legitimate new messages can be discarded without the user receiving an error.

How the history system works

Jev Chat Jarvis does not want to save the same visible messages every time Android reports an accessibility event. To prevent duplicates, the application compares the messages currently visible on screen with the messages it recorded previously.

When part of the previous screen appears again on the next capture, the logic is sensible. The application finds the overlapping sequence and saves only the newer messages that appeared afterward.

The problem occurs when there is no overlap at all.

Inside KbStore.appendLog(), the application checks whether any messages from the current screen also appeared on the previous screen. If nothing matches, the code assumes the user has scrolled backward into older conversation history and refuses to append the current screen.

That assumption can be wrong.

New messages can look exactly like old messages

Consider a busy group conversation. Jev Chat Jarvis captures one screen containing messages A through F. Several messages then arrive before the next successful capture, pushing A through F completely off the screen.

The next visible screen contains messages G through L.

There is now no overlap between the two captures. The application sees exactly the condition its code associates with scrolling backward, so the new screen can be ignored entirely.

Nothing necessarily crashes. There is no corrupted file and no obvious warning. The stored conversation simply jumps from message F to some later point while G through L never enter the history.

That creates a particularly awkward failure for an application whose purpose is interpreting human conversations.

The AI can receive an incomplete version of what happened

Jev Chat Jarvis uses stored history when constructing additional context for its analysis. If an entire screen of new conversation is skipped, later requests can contain a distorted sequence of events.

A user could receive an analysis of someone's intent after the application silently omitted the exact messages that changed the tone of the conversation. A disagreement, correction, apology, request, or decision could disappear from the stored context even though the application otherwise appears to be functioning normally.

The defect does not require unusual input. It only requires enough conversation activity between captures for every previously visible message to disappear from the screen.

The underlying mistake is an assumption about direction

The history code has encountered an ambiguous state and treated it as certain.

No overlap can mean the user scrolled upward into old messages. It can also mean the conversation advanced far enough that the previous screen disappeared.

Those situations look identical if the program only compares message text.

The current implementation chooses the first interpretation and discards the screen. A more reliable design would preserve the new capture when direction cannot be established, or use additional information from Android events and scroll state before deciding that the user moved backward.

Duplicate history is inconvenient. Missing history is considerably harder to detect.

This is a real bug, not a theoretical security concern

The defect is contained in ordinary application logic rather than some exotic Android vulnerability. It does not require an attacker, compromised device, or manipulated network connection.

That simplicity is what makes it interesting. Jev Chat Jarvis can correctly read a conversation, correctly identify the contact, correctly run its models, and still provide those models with incomplete history because one assumption inside the deduplication algorithm was too aggressive.

The project is young and moving quickly, so bugs of this type are unsurprising. The repository already contains thoughtful safeguards around local storage, contact matching, optional history, and message duplication. This particular edge case slips through precisely because the existing logic is attempting to be careful about duplicate data.

Final assessment

Jev Chat Jarvis is technically ambitious, especially for a project that appeared so recently. Reading multiple chat interfaces, maintaining contact context, handling OCR fallbacks, and supplying structured conversation history to AI models involves considerably more state management than a simple reply generator.

The history bug is narrow, but its consequence lands directly in the product's core purpose. An AI assistant can only interpret the conversation it is given. If legitimate new messages silently disappear before reaching that layer, the model can produce a perfectly reasonable answer to an incomplete version of reality.

That is the kind of bug worth fixing early, especially in software designed to understand what people are saying to each other.