Steps to reproduce
- Create a new vault and install the community plugin MCP Connector 3.0.2 (a 2.8 MB bundle, GitHub - istefox/obsidian-mcp-connector: Your Obsidian vault, exposed to Claude and any MCP client. Runs inside Obsidian, on-device semantic search, no cloud round-trip, no binary to download. · GitHub).
- Open Settings, Community plugins, and switch the plugin off, then on.
- Repeat until the window goes blank.
Each load has roughly a 10 to 15 percent chance of crashing. My automated toggle runs crashed within 8 loads.
Did you read and follow the Troubleshooting Guide? [Yes/No]
Yes, with one limit: the crash needs a community plugin, so I cannot reproduce it in the Sandbox vault with restricted mode on. It reproduces in a new scratch vault with this plugin installed. A copy of the plugin bundle patched to skip its startup route ran 24 cycles clean, and a tiny plugin with one loopback socket ran 15 cycles clean, which proves little at this crash rate.
Expected result
The plugin loads every time and the window stays usable.
Actual result
The renderer process dies at random and the window goes blank. I have 12 crash reports between 8 and 13 October. The ones I inspected all show EXC_BAD_ACCESS / SIGSEGV, KERN_INVALID_ADDRESS at 0x0, on the CrRendererMain thread. The frames I could symbolize sit inside V8: ThreadIsolation::LookupWritableJitPage, v8::Unwinder::PCIsInV8, TurboFan CompilationDependencies::DependOnStableMap and v8::Object::Clone. Other reports show OnUvRead and cppgc FreeUnreferencedObject. No plugin function appears in a stack I have seen.
Environment
Obsidian 1.14.4 (Electron 43.7.7), Apple silicon, macOS 27.0.1 (26A434).
The debug info below comes from my everyday vault, which has 9 community plugins enabled. The reproduction runs and the Electron comparison used a separate scratch vault with this plugin installed.
SYSTEM INFO:
Obsidian version: 1.14.4
Installer version: 1.14.4
Operating system: Darwin Kernel Version 27.0.0: Tue Aug 11 21:06:40 PDT 2026; root:xnu-13432.1.9~1/RELEASE_ARM64_T6050 27.0.0
Login status: logged in
Language: en
Catalyst license: insider
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: AnuPpuccin 1.5.0
Snippets enabled: 0
Restricted mode: off
Plugins installed: 10
Plugins enabled: 9
1: Promptbox v1.6.0
2: Dataview v0.5.68
3: Breadcrumbs v4.21.14
4: Text Extractor v0.7.0
5: Link Embed v2.10.5
6: Find Orphaned Images v1.3.0
7: Advanced Tables v0.23.2
8: Bookmarker v0.1.30
9: MCP Connector v3.0.2
Additional information
The control that points at Electron: on the same machine, with the same plugin, I ran the Obsidian 1.12.7 installer (Electron 39.8.3) with a separate user data dir. With the 1.12.7 app code it did 35 loads and no crash. With the 1.14.4 app package loaded by that old installer it did about 38 loads and no crash. At the rates I see on 43.7.7, 38 clean loads would happen by chance well under 2 percent of the time. Loading a newer asar from an older installer is not a supported setup, so treat that second run as indicative only.
Three other users report the same crash, all on Obsidian 1.14.4: one on macOS 27.0.1 while rebuilding a plugin’s embedding index, one on macOS 26.7.1 when enabling the plugin on a fresh install, and one on Windows 11 when toggling the plugin or downloading an embedding model. So it is not specific to macOS 27. Their reports are issues 597 and 609 in istefox/obsidian-mcp-connector.
I have not tested Electron 40 to 42 or other heavy plugins. This is not the large Markdown indexing crash in the thread “Renderer exits and window turns black while indexing large Markdown files”: that one is a SIGTRAP with the V8 heap exhausted and no plugin involved.
Is this a known Electron or V8 problem in Obsidian 1.14.4? I have the .ips files and the steps for the automated toggle test if they help.
.