Skip to content

Build1 publisher3 min readPublished

Kimi Work's feedback button ships your last five agent sessions, not the one you are reporting

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

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

Illustration accompanying Kimi Work's feedback button ships your last five agent sessions, not the one you are reporting
Generated illustration

What happened

  • 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.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

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].

Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories