Build1 distinct publisher3 min readUpdated
RuntimeWire found Moonshot AI's desktop app zips and uploads raw records from the five most recently updated conversations on every feedback submission, with no preview and no consent box.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Moonshot AI's Kimi Work desktop app is built to attach raw diagnostic records from five recent agent conversations every time a user submits feedback, according to a RuntimeWire analysis of the Windows application [1]. The selection is made by recency rather than relevance, so a bug report about one task carries at least four unrelated sessions with it [2][3][1]. The mechanism is not subtle. Kimi Desktop sorts every locally registered Work conversation by last update time, takes the newest five, and asks a bundled background service to build a separate ZIP archive for each one, uploading those archives next to a desktop diagnostic-log package before the feedback text itself goes out [2]. The renderer fires two background operations, feedbackUploadLogs and feedbackUploadRawRecords, in a single Promise.allSettled call [9]. The raw-record handler calls conversations.list, sorts by updatedAt and applies .slice(0, 5); it never receives the current conversation as an argument [3]. An internal comment in the shipped preload code describes the method as exporting and uploading the five most recent sessions, with the selection fixed in the desktop main process [4]. If the session you are complaining about is not among the five most recently touched, it may not be in the bundle at all [2]. RuntimeWire confirmed the behaviour on an installed copy of Kimi Desktop 3.1.5 by blocking outbound traffic from Kimi.exe with a Windows firewall rule [5]. Submitting the phrase "RuntimeWire test." from the Plugins feedback screen triggered a multipart upload of the diagnostic archive, followed by upload attempts for archives tied to five distinct recent conversation IDs [6]. All five failed with net::ERR_NETWORK_ACCESS_DENIED, and Kimi's own main-process log recorded five failures inside five milliseconds before printing "[FeedbackRawRecords] ok: 0/5 archives uploaded in 166ms" [7]. Notably, the Plugins form disables user image attachments and labels itself as coming from the plugin hub, yet it still invoked the same global collection routine used by the account menu, an active conversation and the generated-website preview [8]. What is in those archives matters more than the plumbing. For each conversation, the bundled component Daimon, version 0.5.49 in the package examined, locates the main agent's wire.jsonl plus subagent records, admits as many as 100 record files per conversation and reads the last 500 JSONL records from each [13][14]. That is up to 50,000 records per conversation and 250,000 across the five [3]. Kimi's own documentation calls agents/main/wire.jsonl the main agent's "complete communication record" and says the traces carry tool schemas, request parameters and MCP tool listings [16]. Each ZIP is capped at 8 MiB, giving a 40 MiB client-side ceiling across the five, plus the log package [15]. Daimon does sanitize, but only by shape: it strips large base64-looking blobs, replaces oversized values with length-and-hash markers and truncates ordinary strings at 8,192 characters, with no check for passwords, API keys, access tokens or private source code [17]. The interface says none of this. The English form asks the user to describe a problem and mentions that images can be uploaded or pasted; there is no attachment preview, no consent box, no per-session selector and no statement of the combined size [11]. Object names for the uploaded archives are tucked into a hidden metadata prefix in the feedback body under rawRecordsObjectNames, while the visible file_object_names field is reserved for images the user chose [10]. Kimi's public help page, current when RuntimeWire reviewed it on 15 August, says in-product reports automatically attach "device and account context" and does not mention raw session records [12]. For anyone running this on managed hardware, the practical read is that a single support gesture by one employee is a bulk export of recent agent activity, including tool wiring, from that machine [1][2][16]. Watch whether Moonshot changes the help text, adds a preview or scopes collection to the reported conversation, and whether builds after 3.1.5 and Daimon 0.5.49 keep the same handler [5][13].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Moonshot AI's Kimi Work desktop app is designed to attach raw diagnostic records from five recent agent conversations whenever a user submits feedback, according to a RuntimeWire analysis of the Windows application.
Kimi Desktop sorts every locally registered Work conversation by its last update time, takes the newest five, and asks a bundled background service to create a separate ZIP archive for each one, uploading those archives alongside a desktop diagnostic-log package before sending the feedback text.
The raw-record handler calls conversations.list, sorts the returned conversations by updatedAt and applies .slice(0, 5); it does not receive the current conversation as an argument.
An internal comment in Kimi's shipped preload code describes the method as exporting and uploading the five most recent sessions, with the selection fixed in the desktop main process.
RuntimeWire confirmed the behaviour on an installed copy of Kimi Desktop 3.1.5 using a Windows firewall rule that blocked outbound traffic from Kimi.exe.
The test opened feedback from Kimi Work's Plugins page and submitted the phrase "RuntimeWire test."; Kimi immediately attempted a multipart upload containing its diagnostic archive, then tried to upload raw-record archives associated with five distinct recent conversation IDs.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Named code paths plus reproduced runtime behaviour, one outlet
The claims rest on specific, checkable artifacts: the conversations.list / updatedAt / .slice(0, 5) handler, the Promise.allSettled renderer block, Daimon 0.5.49's registered conversations.getRawRecordsArchive route, and a firewall-blocked reproduction on Kimi Desktop 3.1.5 that produced five denied uploads and the app's own '0/5 archives uploaded' log line. Documentation claims quote the vendor's help page and session docs. What holds the score below the top band is that everything comes from a single publisher's single-machine test, with no vendor response and no independent replication.
Confirmed in a shipped release; user scale unreported
The behaviour is not a prototype: it executes in production code paths of Kimi Desktop 3.1.5 with a bundled Daimon 0.5.49 component, and it is reachable from four ordinary feedback entry points, so any user who files in-product feedback is exposed. But the cluster supplies no install base, enterprise deployment count, telemetry volume or vendor usage disclosure, so the breadth of real-world exposure cannot be quantified.
Verified mechanism, but worst-case volumes and harm remain theoretical
The core mechanism and disclosure gap are demonstrated, so the framing is largely earned. The modest positive gap reflects that the headline word 'secretly' and the largest figures - 40 MiB and up to 250,000 records per submission - are code-derived ceilings rather than measured payloads; the test's uploads were deliberately blocked, no secret or customer datum is shown to have left a machine, the vendor's privacy policy does cover conversation content and logs at a broad level, and the report itself notes no remote exploitation path was found.
Vendor benefits from broad diagnostics; sole-source scoop framing
Two visible incentive pressures. Moonshot AI gains debugging and product-improvement value from bundling recent session records, and the path of least friction is a broad privacy policy plus a help page limited to 'device and account context' rather than an explicit in-form disclosure or session picker. On the publishing side, RuntimeWire presents this as a scoop and states there was no prior public result for the internal method name, giving it an interest in first-mover framing; the cluster shows no vendor comment or adversarial review to offset that. No commercial relationship or funding pressure is disclosed either way, so the score stays mid-range.
Mechanism well evidenced, exposure scale and vendor position unknown
Confidence is high that the described collection behaviour exists and executes in the examined release, because code detail and a reproduced runtime trace agree. It is materially lower on consequences: single publisher, single machine, one app version, no vendor statement, nothing about server-side handling of uploaded archives, and no measurement of how much data a real submission carries or how many users are affected.
build
A consumer desktop client shipped an internal AI gateway, and a cleartext token store1 distinct publisher
build
Kimi Desktop's second binary: mutable CDN path, no Windows checksum, no signer check1 distinct publisher
invest
The chips never move: Washington's fix for the Southeast Asia compute loophole1 distinct publisher
build
PerceptionBench puts a number on the step your pipeline treats as free1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.