Report conversations — replies to your reports, inside the app

What it is

When you send a bug report, a feature idea, a question or general feedback from the app's Feedback button, the app also opens a conversation about it with the support team. Someone on the support side can then answer you right inside the app, and you can answer back — you do not need to have Get Help turned on, and nothing about how your report itself is sent changes.

For any report somebody else sent — a bug report, a feature idea, a question or a feedback note, that conversation is the whole answer on the support side: a person reads it and writes back, and nothing starts a session in the background to work on it automatically. The person who sent it is told once that it arrived, and support opens the conversation onto a reply that has already been drafted for them to read, edit and send — the assistant never sends it, and never answers a report conversation at all. The operator's own reports are the exception: those keep starting their investigation, because that is how their own bugs get fixed.

The conversation belongs to you and starts with your report's own words, labelled with its kind (for example "Bug report: …"). Only people answer it: the app's AI assistant never replies to a report conversation.

The same is true whichever door the report left by. An assistant filing a report on your behalf (rather than you clicking the Feedback button) reaches the app through the same route, and that report opens its conversation too — one report, one conversation, either way.

Where to find it

• Your reports — open the Feedback button; once you have sent at least one report, a Your reports row sits at the top of the form. It opens a small window listing your reports, each with where it stands: on its way, waiting on an agent, answered, or resolved.
• A dot on the Feedback button — shown while a reply from support is unread.
• The reply notification — "An agent replied to your report". Clicking it opens Your reports on that conversation. Phones paired with the app get the same notice.

On the desktop Your reports is a compact popover in the corner of the window (the same corner and size as the Get Help widget), so the rest of the app stays usable behind it and Esc closes it. On a phone it is a screen inside the normal layout, like every other hub: the app's tab bar and breadcrumb stay on screen, the breadcrumb names the screen, and Back steps out of it — first from an open conversation back to the list, then out of the screen. Either way it opens through the one door openYourReports; the phone screen carries no close button, because the breadcrumb already carries Back.

How it behaves

• It opens on the newest message. Opening a conversation puts the TOP of its newest message at the top of the window, so a long reply from support reads from its first line instead of starting in the middle — the same way a session transcript lands on its latest reply (the Get Help chat works the same way). A newer message that arrives while you have not scrolled, or while you are reading at the bottom, is shown from its top too; scroll up to read older messages and nothing moves you.
• Replying. While a report is open with the support team, a reply box sits at the bottom of it. Your reply goes back into the support queue. Once support resolves it, it becomes read-only and says so — send a new report if you need more help. A report that has not reached support yet is read-only too, until it arrives.
• You are told once, then a person answers. Send a bug report, a feature idea, a question or a feedback note and you get a single "we've got your report and someone is already looking into it" email — never a second one, however many times the report is delivered.
• It carries your report's own files. Your screenshots, anything else you attached, and the logs the app collected with the report ride the conversation as real attachments, so support opens them on the ticket instead of hunting through the report's email. They sit on the conversation's opening message — the report's own words — so nothing is shown twice. Nothing else rides along (no device details), and replies in the conversation are text only.
• Offline is fine. A report saved to send later still gets its conversation; if the conversation could not open, the app keeps retrying for about a day and never opens a second one.
• A report you kept on your computer opens nothing. With sending turned off, or a report that was lost, no conversation is opened.
• Nothing else of Get Help comes with it. With Get Help off, Your reports shows only your report conversations — no question box, no assistant, no Help Center.
• Switching it off. Turn off Report conversations in Settings → Lab: new reports stop opening a conversation and Your reports is hidden. It is on by default.

For agents

• Contract: .claude/memory/contracts/helpdesk-report-conversations-contract.md (21 named rules); map: the "Your reports" entry in .claude/memory/helpdesk-part2.md.
• Handing somebody else's report over. shouldHandInAppReportToHelpDesk in src/main/services/bug/in-app-report-helpdesk-route.ts is the ONE decision — a bug/feature report, the reporter's own address not matching the signed-in one, and the report-conversations gate on. Its sibling shouldDeferInAppEmailCopy (src/main/services/intake/in-app-cid-dedup.ts) makes the email copy stand down for a [CID:]-marked copy, because the dual-write claim spawns whichever arrival wins and the SAVED report is the authority. The listener still claims the row (that is what collapses the dual write and gives the report its card) and deletes the relay copy. handInAppReportToHelpDesk (src/main/services/helpdesk/hand-off-in-app-report.ts) opens the report's Help Desk conversation through openReceivedReportConversation (src/main/services/helpdesk/helpdesk-report-conversation.ts) — the receiving computer's half, and the only one that exists when the sending build predates this feature — then marks the row help_desk_ticket = 1, sends the one acknowledgement through buildReporterAck('liaison'), and hands a draft to the renderer, which keeps it in useReplyDraftStore under helpdesk:<threadId>. One thread, either way: the write is under the report's own correlation id, and the relay refuses the second writer (writeThread's alreadyOwned), which is an ordinary outcome and not a retry. A conversation's TEXT is its message list — question only titles the ticket — so the box that opens the thread writes the report as its opening user message too (skipped when alreadyOwned, since the sending install wrote its own then). That opening turn is keyed on the report's own correlation id, because the open is re-run whenever the relay copy outlives its delete and the relay allows a same-owner re-write — the relay stores a message at messages/<messageId>, so the key makes a re-run an upsert of one turn rather than a second identical one (and it must be a real uuid: the relay validates it). The console reads a thread through withOpeningTurn (src/main/services/helpdesk/helpdesk-thread-opening-turn.ts): a thread carrying a question and NO messages reads as its own opening turn, so a conversation that arrived without a body is still readable, and the state is logged rather than repaired in silence. Both console reads of that thread — HELPDESK_DEV_GET_THREAD and HELPDESK_DEV_DRAFT_REPLY — go through it, so a thread the console displays is one the operator can also re-draft.
• Opening: openReportConversation in src/main/services/helpdesk/helpdesk-report-conversation.ts, fired (never awaited) from the feedback:send handler after sendReport settles; only a delivered outcome or kept with keptBecause: 'all-legs-failed' opens one. The local row is help_requests.report_correlation_id (unique); the cloud thread id IS the report's correlationId, escalated with notifyDeveloper: false and no device/system info. The hourly retry rides the feedback outbox drain (repairPendingReportConversations: 5-minute floor, 24-hour give-up, batch 20).
• The report's own files ride that opening turn. The sending install hands them to escalateHelpRequest as openingTurnFiles, so they are appended WITH the request's own question rather than as a second turn repeating the report (which is what the first cut did — caught in the AI code review 2026-10-01). A report sent with attachLogs: false supplies no logs at all. On the receiving side openReceivedReportConversation attaches them to the opening turn it writes. Bytes go to the same Storage prefix a reply's attachment uses, under the SUPPORT caps (@shared/helpdesk/attachment-caps), uploaded from MAIN by src/main/services/helpdesk/helpdesk-attachment-upload.ts — the renderer's uploader cannot run where that turn is written, which is the named exception in helpdesk-realtime-contract. Reporter text attachments are scrubbed at that boundary with the same scrubber the email leg uses (scrubTextAttachments); the collected logs arrive scrubbed. A thread the receiving box opened from a relayed report carries the reporter's pictures and documents — a cloud record cannot carry the logs — and a conversation an OLDER build opened keeps its text and NO files, because the relay refuses every append that does not carry the thread's own owner key (checkThreadOwner).
• Gating: helpdeskUserAccess() in src/main/ipc/helpdesk/shared.ts — full (Get Help on), reports (Get Help off, feature on: list / get / reply / notifications narrowed to the caller's own report rows), none. HELPDESK_ASK_FOLLOWUP and HELPDESK_ESCALATE refuse a report row even with Get Help on. The reply listener also runs while a report conversation is receivable.
• Renderer: HelpdeskReportsPanel (host HelpdeskReportsPanelHost on the store's reportsOpen), store actions openReports / loadReportRequests (list route with { reportsOnly: true }).
• Operator side: the console row carries fromReport (stand-in reporter uid report:<id>, or a report this computer received) and keeps its own row; the Tracker shows only the report's card (openGetHelpCard skips a report id; the report claim retires a Get Help card opened first).
• Flag: unreleased feature report-conversations, setting reportConversationsEnabled (default on).

Related

• bug-report-intake.md — how the Feedback form's report is received, and what happens to it after it leaves the app.
• helpdesk.md — the in-app help assistant and the support console where the team answers report conversations alongside ordinary escalated questions.