https://bugs.documentfoundation.org/show_bug.cgi?id=172229
--- Comment #2 from [email protected] --- and will attach it to this bug within a few days. The extension where I encountered this is a local fork of mcp-libre (github.com/patrup/mcp-libre), an MCP — Model Context Protocol — server integration for LibreOffice. The fork has grown to roughly 1,500 lines exposing 43 tools across Writer, Calc, Impress, and Draw, plus a queue/AsyncCallback architecture added during the debugging process for this very issue. I'm stripping it down to the minimal repro case — a single tool, no async machinery, no queue — so the bug surface is as small as possible and triage can focus on the threading/filesystem boundary rather than incidental complexity. To clarify the regression timing: the extension worked correctly on earlier macOS Tahoe releases (26.0 through 26.4) paired with LibreOffice 26.2.x. The hang began appearing when macOS Tahoe 26.5 and a LibreOffice 26.2.x point update landed within a day or two of each other in mid-May, so I can't yet say with certainty which of the two updates is the proximate cause — only that the combination is what produces the failure on Apple Silicon. I'll try to isolate this further during the repro work. A few additional findings from continued testing since I filed: XDispatchHelper.executeDispatch(frame, ".uno:Save", "", 0, ()) from the same background thread context produces the identical hang as direct storeToURL(). The dispatcher framework does not route around the underlying issue. The hang also occurs on read calls (e.g. getCurrentComponent followed by property reads) when they immediately precede a save attempt, suggesting the main thread may already be entering an unrecoverable state before the save dispatch is issued. I'm trying to isolate whether this is a separate symptom or the same hang manifesting earlier in the call sequence. In-RAM operations against the same document on the same background thread (insertString, cell setValue/setFormula, property reads not coupled with saves) all execute cleanly and return normally. The boundary appears to be specifically operations that touch the filesystem. If sharing relevant code paths from the existing extension would help (HTTP server initialization, UNO dispatch thread context, AsyncCallback registration via bundled offapi.rdb), let me know and I can post them as separate comments while the repro is being prepared. I use LibreOffice with Claude daily and the MCP extension has been working beautifully since I set it up a couple of months ago and become part of my daily work and personal routine, so having it break on the Mac side this last week has been genuinely disrupting. Happy to put in the work on the repro side to help get this resolved. Thanks again!!! -- You are receiving this mail because: You are the assignee for the bug.
