Bug Reporting / System Issues

Description: Co-Pilot does not consistently restore the most recently used conversation thread when switching between claims. When I am inside a claim and navigate to Co-Pilot from another menu section, such as Overview , Timeline , or Files , Co-Pilot correctly opens the most recently used conversation thread for that claim. The problem occurs when Co-Pilot is already active on the screen and I switch directly to a different claim. In that situation, Co-Pilot stays selected in the navigation, but it defaults to the new-thread landing page for the newly selected claim, even when that claim has existing Co-Pilot conversation threads. After switching to the new claim, I can click any other menu section, such as Overview , Timeline , or Files , and then return to Co-Pilot . Co-Pilot then correctly opens the most recently used conversation thread for that claim. The issue is limited to switching claims while Co-Pilot remains the active section. Steps to reproduce: Open Claim A. Select Co-Pilot and use an existing conversation thread. Leave Co-Pilot selected in the navigation. Switch directly to Claim B, which already has existing Co-Pilot conversation threads. Co-Pilot displays the new-thread landing page instead of Claim B’s most recently used conversation thread. In Claim B, click another menu section, such as Overview , Timeline , or Files . Click Co-Pilot again. Co-Pilot opens Claim B’s most recently used conversation thread. Expected behavior: When switching to a claim while Co-Pilot is already selected, Co-Pilot should open that claim’s most recently used conversation thread when one exists. The new-thread landing page should appear only when the claim has no existing Co-Pilot conversation history or when the user intentionally starts a new conversation. Actual behavior: Switching claims while Co-Pilot remains active defaults to the new-thread landing page. The most recently used thread appears only after navigating to another menu section and then returning to Co-Pilot. Impact: This interrupts the workflow when returning to claims to continue existing Co-Pilot conversations. Users must leave Co-Pilot and return to it before the correct recent thread appears. Suggested fix: When the active claim changes while Co-Pilot is selected, load the most recently used Co-Pilot conversation thread for the newly selected claim.

Draft text selection triggers edit mode and clears the selection before copying Description: When I click and drag across text in a chat draft card to highlight it for copying, an editing box opens automatically. When I then click the highlighted text to copy it, the selection disappears instead. The draft card already includes an Edit button in the upper-left corner for deliberately entering edit mode. Text selection and copying should work independently of that control. The edit box should appear only when the user selects Edit . I tested several ways to select the text, and the same issue occurs consistently. The only workaround I found is quickly triple-clicking the text, which lets me highlight and copy it successfully. Steps to reproduce: Create a draft in the chat draft card. Click and drag across any draft text to highlight it. An editing box opens automatically. Click the highlighted text to copy it. The text selection disappears before it can be copied. Expected behavior: Users should be able to click and drag to highlight draft text, then copy the selection without entering edit mode or losing the selection. The edit box should open only after selecting the Edit button. Actual behavior: Clicking and dragging to highlight text opens the editing box. Clicking the selected text then clears the highlight, preventing the normal copy action. Workaround: Quickly triple-clicking the text allows it to be highlighted and copied. Video demonstration: https://www.loom.com/share/9662481d7fa34cca9e0b3e42d3bcfb3f

Summary Gmail drafts created by Brelly use Brelly’s formatting instead of the user’s Gmail default text style. Steps to reproduce Ask Brelly to create a Gmail draft. Open the created draft in Gmail. Add or edit text in the message body. Expected result The Brelly-created content should inherit the user’s Gmail default font, size, color, and formatting so later edits match automatically. Actual result The Brelly-created text uses a different font and formatting. Any text the user adds in Gmail appears inconsistent with the existing draft unless they manually reformat the entire email. Impact Users must manually select and reformat the entire message before sending. This slows down drafting and risks sending an email with visibly inconsistent formatting. Requested fix Create Gmail drafts as plain text or apply the connected Gmail account’s default compose style when generating the draft. Sep 30, 2026, 5:32 PM

I previously reported inconsistent paste behavior tied to different copy and paste methods, and some work was done to improve that. This report covers a new issue I did not notice before: extra spacing is being introduced when copied chat content is pasted into Word, Gmail, and Brelly Docs. To help isolate it clearly, I tested multiple copy and paste scenarios and attached organized examples for each one. The full findings, file-by-file explanations, and supporting evidence are included in the attached Clipboard Formatting Bug Report and related files.

Hi Brelly Support, I am seeing two related problems in project 96a63fc5-a724-474c-9ff1-29ed88c49fa9 (Leo DeAngelo claim, Allstate claim 0802559369). Co‑Pilot regression reading “DeAngelo Final - Integrity.pdf” Context: In a prior Co‑Pilot conversation on this same project, Co‑Pilot successfully read my final roof estimate file named DeAngelo Final - Integrity.pdf. It parsed line items, totals, and helped build financial breakdowns and carrier correspondence based on that file. In the current Co‑Pilot thread, it can no longer reach that same file, even though I still see it in the Files tab. Symptoms in the current thread: Co‑Pilot calls available_files_retriever_get_available_files. The system returns a very long list of file summaries. The response delivered to Co‑Pilot is truncated: it only includes the beginning and end of the list, not the middle. The entry for DeAngelo Final - Integrity.pdf is not visible in the truncated view, so Co‑Pilot cannot see its File ID. Co‑Pilot then tries files_retriever_get_files using one of the visible File IDs (for example d38c0a63-d6ac-4346-ba0f-fe15434058f3), and gets the message: “No files are currently available.” Later, Co‑Pilot uses files_retriever_get_files on a different File ID (9cf1d722-b960-4b43-9b1b-eeaa305d121e, which is Deangelo Policy.pdf), and that call works. So the content retriever is not completely broken for this project. It works for at least some PDFs but fails or cannot be targeted correctly for DeAngelo Final - Integrity.pdf. Because the tools do not support searching by filename to get a File ID, Co‑Pilot is stuck. It knows a file with that name exists (from earlier work and from what I tell it), but it cannot see the current File ID in the truncated file list and cannot read the estimate content in this thread. Expected behavior: Co‑Pilot should be able to see the DeAngelo Final - Integrity.pdf file in the file list and retrieve its content in any thread attached to this project, just like it did in earlier conversations. The file list that Co‑Pilot receives should not be truncated in a way that hides the ID of a key project file, or there should be a way to search/filter by filename and get the right File ID. File IDs that were valid in earlier sessions should not start returning “No files are currently available” for the same project unless the file was actually deleted. Actual behavior: Co‑Pilot can read some PDFs (for example Deangelo Policy.pdf) but is effectively blind to DeAngelo Final - Integrity.pdf in this thread. It keeps asking me to paste the F9 notes manually because it cannot see or resolve the estimate file, even though it used that exact file successfully in a prior conversation. Request: Please investigate why available_files_retriever_get_available_files is returning a list so large that the middle entries, including DeAngelo Final - Integrity.pdf, are not visible to Co‑Pilot. Either adjust the tool behavior for large projects, or provide a search-by-filename endpoint that Co‑Pilot can use to get the correct File ID. Also check why the File ID d38c0a63-d6ac-4346-ba0f-fe15434058f3 returned “No files are currently available” and whether that indicates a broken mapping for one of my estimate files. The goal is that Co‑Pilot can reliably read DeAngelo Final - Integrity.pdf again, including the F9 notes on line items 2, 15, and 20, without me having to paste them by hand. Duplicate estimate uploads from the Financials tab Separate issue in the same project: In the Financials tab, when I add an estimate, the UI forces me to upload the estimate file even though the same PDF already exists in the Files section. After I upload through Financials, a second file entry with the same filename appears in the main Files list. I end up with two copies of the same estimate in Files with identical filenames. This feels wrong for a couple of reasons: It creates confusion about which “DeAngelo Final - Integrity.pdf” is the “real” one. It increases the surface area for bugs like the one above, since Co‑Pilot and the system now have multiple file objects with the same name. Expected behavior: When I link an estimate from the Financials tab, I should be able to select an existing file from the project instead of being forced to upload a duplicate. If a file with the same name already exists and I upload it again, the system should at least warn me or give me the option to reuse the existing file. Request: Please review the Financials tab behavior so that connecting an estimate to Financials does not silently create duplicate file entries with the same filename in the Files area. Ideally, let me choose an existing estimate PDF that is already uploaded. Thank you for taking a look at both of these issues. Once they are resolved, Co‑Pilot will be able to use my final estimate consistently, and I will not end up with multiple “DeAngelo Final - Integrity.pdf” entries in the same claim.

In the overview tab under policy details, it lists the deductibles as $1 instead of 1% or the actual dollar amount

I've imported my carrier estimate and my supplement estimates but the Financial tab isn't updating with the information.

Copying text from Brelly produces inconsistent results depending on theme (dark vs light) and whether the selection is full or partial. For comparison, copying from ChatGPT (in both dark and light mode) does not introduce wrapper or container styling and preserves clean formatting, which reflects the expected behavior. An attached document is included that demonstrates each condition and its resulting paste behavior for verification. Observed behavior: Dark mode (full or partial selection, highlight -> copy -> paste) * Formatting is preserved * Wrapper or container styling is present * Text appears light gray Light mode (partial selection, highlight -> copy -> paste) * Formatting is preserved * Wrapper or container styling is present * Text appears black Light mode (full selection, highlight -> copy -> paste) * Formatting is preserved * No wrapper or container styling * Text appears black Copy action at bottom of response (any mode) * No formatting * No wrapper or container styling * Text appears black Core issue: There is no consistent way to copy formatted text without also including unwanted UI wrapper styling, except in the specific case of full selection in light mode. Expected behavior: * Copying text (full or partial) should always: * Preserve formatting (lists, spacing, structure) * Exclude UI-specific wrapper or container styling * Normalize text color for readability on light backgrounds Suggested fix: * Ensure that all copy operations strip UI or container-level HTML and only retain semantic formatting * Make copy behavior consistent regardless of: * Theme (dark or light) * Selection scope (partial or full) Secondary suggestion: * Update the copy action at the bottom of responses to default to formatted text without UI styling instead of plain text, so users can copy clean, structured content without losing formatting Impact: Users cannot reliably copy formatted content into emails, documents, or other tools without manual cleanup, especially when copying partial sections or working in dark mode.