[macOS 26] McpProcess IPC crash loop on startup — agent execution fails until legacyMcpMode workaround applied

Support Bug Reports
, , , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

. Bug #1 — McpProcess Crashes on Startup (Critical)

Description
On every Cursor startup, the McpProcess utility process fails to initialize and crashes in a retry loop before giving up and falling back to legacy in-window MCP. This causes the agent execution provider to become unresponsive when the user attempts to run any task.

Observed Behavior
• McpProcess times out waiting for ipcReady after 10,000ms on every attempt
• Cursor retries with exponential backoff: 1s → 2s → 4s → 8s → 16s
• After 6 crashes within 600,000ms, Cursor gives up and falls back to legacy MCP
• First agent task after startup fails with: “The agent execution provider did not respond in time”
• Subsequent tasks succeed once the legacy MCP path is established

Log Evidence
[McpProcess] ipcReady wait failed [McpProcess] timed out waiting for ipcReady after 10000ms
[McpProcess] crash detected (attempt 1), retrying in 1000ms
[McpProcess] crash detected (attempt 2), retrying in 2000ms
[McpProcess] crash detected (attempt 3), retrying in 4000ms
[McpProcess] crash detected (attempt 4), retrying in 8000ms
[McpProcess] crash detected (attempt 5), retrying in 16000ms
[McpProcess] giving up after 6 crashes within 600000ms; falling back to legacy in-window MCP
[McpProcess] gave up after exceeding restart budget; renderer will fall back to legacy MCP path

Root Cause Hypothesis
macOS 26 appears to have changed IPC socket or sandboxing behavior for Electron utility processes. The McpProcess binary (at Contents/Resources/app/out/vs/code/electron-utility/mcpProcess/mcpProcessMain.js) fails to establish its IPC channel before the 10s timeout. Running the Cursor binary directly from the terminal produces a ‘trace trap’ (SIGTRAP), suggesting the OS is halting the utility process before it can run. Code signing is valid (Notarized Developer ID) so this is not a Gatekeeper issue.

Workaround
Adding the following to User Settings JSON bypasses the utility process entirely and forces the legacy in-window MCP path, which functions correctly:
“cursor.agent.legacyMcpMode”: true

Impact
• Every Cursor startup wastes ~90 seconds on retry attempts before fallback
• First agent task on every session fails with a timeout error
• Users with no MCP servers configured are affected (not a server config issue)

  1. Bug #2 — Excessive Disk Writes Triggering macOS Throttling

Description
A Cursor process was throttled and killed by macOS for writing 2.14 GB of data in approximately 9 minutes, far exceeding the macOS limit of 24.86 KB/sec sustained write rate.

Crash Report Details
Incident Date 2026-05-14 07:41:05 +0200
Cursor Version 3.3.30
PID 65415
Write Volume 2,147.50 MB over 556 seconds
Write Rate 3,864 KB/sec average (limit: 24.86 KB/sec)
Duration ~9 minutes 16 seconds
macOS Action Process throttled / killed

Stack Trace
The heaviest stack identified in the diagnostic report:
sqlite3_exec → sqlite3_step → sqlite3VdbeExec → sqlite3VdbeHalt
→ vdbeCommit → pagerWalFrames → walWriteOneFrame → pwrite
The write-heavy thread was executing SQLite WAL (Write-Ahead Log) frame commits via vscode-sqlite3.node, the native SQLite module used for Cursor’s local agent storage, chat history, and workspace indexing databases.

Impact
• Process killed by macOS after exceeding disk write budget
• Potential data corruption risk if SQLite commits are interrupted mid-transaction
• Abnormal write amplification: 155× the allowed sustained write rate

  1. Bug #3 — Remote-SSH Extension Prompt Loop

Description
On every Cursor startup, before any remote connection is made, a notification appeared prompting the user to install the Remote - SSH extension:
“Extension ‘Remote - SSH’ is required to open the remote window. Do you want to install the extension?”
Clicking ‘Install and Reload’ installs the extension and reloads Cursor, but the same prompt reappears on the next startup.

Root Cause
Cursor ships its own Remote SSH fork as anysphere.remote-ssh (version 1.0.49 was installed). However, Cursor’s remote window restoration code checks for the Microsoft extension ID ms-vscode-remote.remote-ssh instead of its own fork’s ID. On startup, Cursor attempts to restore the last remote session (qualif or prod as defined in remote.SSH.remotePlatform settings) and triggers this check, finding the Microsoft ID absent even though the Anysphere fork is present and functional.

Settings at Time of Issue
“remote.SSH.remotePlatform”: { “qualif”: “linux”, “prod”: “linux” }

Workaround
Clearing Cursor’s saved remote window state (globalStorage) prevented the auto-reconnect on startup and stopped the prompt from appearing. The underlying ID mismatch in the dependency check should be corrected in the remote window restoration code.

Steps to Reproduce

Install Cursor on macOS 26.3.1 (Build 25D2128), Apple Silicon (arm64)
Have zero MCP servers configured (~/.cursor/mcp.json absent, no mcpServers in settings.json)
Launch Cursor
Wait ~90 seconds
Attempt any agent task (chat, composer, etc.)

Expected: Agent responds normally
Actual: McpProcess crashes 6 times with exponential backoff (1s→2s→4s→8s→16s), falls back to legacy MCP, first agent task fails with “The agent execution provider did not respond in time”
Reproducible: 100% — happens on every cold start
Workaround: Add “cursor.agent.legacyMcpMode”: true to User Settings JSON

Expected Behavior

Cursor starts normally, the McpProcess utility initializes successfully within the 10-second timeout, and the agent is immediately ready to handle tasks without any retry loop or fallback.

Operating System

MacOS

Version Information

Cursor Version3.4.17Electron Framework39.8.1OSmacOS 26.3.1 (Build 25D2128)Architecturearm64e (Apple Silicon)HardwareMac Mini (Mac14,12) — 10 cores, 32 GB RAMMCP SDK@modelcontextprotocol/sdk (bundled)

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the report. The level of detail, repro steps, and log analysis are above average and really helpful. A few notes:

About splitting into threads. The report mixes three different bugs with different root causes (McpProcess IPC, SQLite disk writes, Remote-SSH prompt loop). To track each one correctly and link it to the right internal tickets, it works best if each bug is in its own thread. Can you split it into three separate posts? Keep this one as the summary / Bug #1 (McpProcess), and create new ones for Bug #2 and Bug #3.

About cursor.agent.legacyMcpMode. That setting doesn’t exist in the Cursor codebase. What you see as “it works after adding it” is likely just the automatic fallback to the legacy in-window MCP, which already happens after the retry budget is exhausted (~90s). The setting itself does nothing. Where did that name come from, logs or an AI suggestion? If it came from an AI suggestion, that’s a hallucination.

Real workaround right now if you want to skip the 90s retry loop: there isn’t one (the fallback happens automatically). If you can confirm that the ipcReady timeout goes away in 3.4.17 after some specific environment change (for example disabling security tooling, antivirus, or granting specific macOS permissions), that would really help with diagnosis.

About Bug #2 and Bug #3 (after you split them into threads), both fall into known bug classes:

For Bug #1, a Console.app crash report for McpProcess would be useful (or Diagnostics → User Reports filtered by mcpProcess). If you can attach that, it usually shows the exit code, signal, or the library where the process dies. SIGTRAP when running the binary directly is also interesting, if you can share the full terminal output from running it, we can take a look.

I can’t share an ETA for fixes.

7

Hello,

Thanks for the heads-up. I should have mentioned it upfront — the log analysis and report structure were AI-assisted, though all the data, logs, and observations are genuine and from my own machine.

I’ve created the two separate threads for Bug #2 and Bug #3 as requested.

Thanks again for the quick and detailed response.

Oh I removed the line ““cursor.agent.legacyMcpMode”: true” from open -a “Cursor” ~/Library/Application\ Support/Cursor/User/settings.json and of course you were right. It is working as you said.

8

Thanks for confirming. Glad we cleared up the legacyMcpMode placebo so it won’t confuse other users who find this thread. AI-assisted analysis is fine, but it’s better to label any hallucinated settings as assumed in the report.

Splitting into separate threads is great, thanks. Let’s keep this thread for Bug #1 McpProcess.

To move forward with diagnosing McpProcess on macOS 26, we still need these artifacts:

  1. The McpProcess crash report from Console.app, or via Diagnostics > User Reports with the mcpProcess filter. It should include the exit code, signal, and the frame where the utility process crashes.
  2. Full terminal output when you run the binary directly and hit SIGTRAP trace trap. If you can run it with DYLD_PRINT_LIBRARIES=1, even better. That will show which dylib the loader trips on.
  3. If you have any security tooling installed like Little Snitch, antivirus, EDR, or MDM with system extensions, tell us exactly which one. macOS 26 changed constraints around utility processes, and some of these tools trigger SIGTRAP before the process can bring up IPC.

I can’t share an ETA for a fix yet.

9

Here are the results for the three points:

1. McpProcess crash report

No crash report for mcpProcess found anywhere in Diagnostics → User Reports, including the Retired folder. macOS 26 does not appear to generate a dedicated crash report for this utility child process.

2. SIGTRAP with DYLD_PRINT_LIBRARIES

Same result as before — process dies immediately before any dylib output is produced:

zsh: trace trap  DYLD_PRINT_LIBRARIES=1 /Applications/Cursor.app/Contents/MacOS/Cursor   2>&1 |
zsh: done        head -50

No output at all, which suggests the process is being killed before dyld even starts loading libraries.

3. Security tooling

No MDM enrollment. One relevant system extension was active:

  • Little Snitch Mini (at.obdev.littlesnitchmini.networkextension, version 1.9/1183) — network extension, activated and enabled

This matches exactly the pattern you described: a network/system extension triggering SIGTRAP on utility processes under macOS 26. I have since uninstalled Little Snitch Mini completely.

10

Hey, thanks for the detailed follow-up. Three useful data points:

  1. The fact that macOS 26 doesn’t generate a crash report for the child utility process is an important signal by itself, noted.
  2. A SIGTRAP before any DYLD_PRINT_LIBRARIES=1 output means the process is getting killed before dyld even starts, so at the kernel or codesign validation stage. That’s a very typical pattern for third-party system extensions that hook process spawning.
  3. Little Snitch Mini is the most likely suspect. On macOS 26 the rules for utility process IPC got stricter, and network or proxy extensions sometimes crash Electron child processes in exactly this way.

Main thing I want to confirm: after removing Little Snitch Mini, please do a full reboot (a system extension can stay unloaded until a reboot), then check two things:

  • In the Cursor logs, do the lines [McpProcess] ipcReady wait failed and crash detected (attempt N) disappear on a cold start?
  • Does the first agent task run without the 90s delay and without the error “agent execution provider did not respond in time”?

If yes, that confirms the hypothesis, and I’ll file it as a separate macOS 26 system extensions compatibility issue. If the SIGTRAP is still there, then it’s not LSM and we’ll keep digging. In that case it’d be helpful to run sudo systemextensionsctl list after the reboot to make sure no other active system extensions are left.

I can’t share an ETA for a fix yet. Let me know how the reboot check goes.

11

Update after reboot with Little Snitch Mini fully removed:

McpProcess crash loop is still present. The ipcReady wait failed and crash detected (attempt N) errors are still appearing on every cold start.

SIGTRAP still occurs when running the binary directly with DYLD_PRINT_LIBRARIES=1 — process dies before dyld produces any output, same as before.

Remaining system extensions (neither are network extensions):

  • com.splitmedialabs.virtcam.extension (1.6) — CMIO camera extension
  • com.logi.ghub.audiooverride (1.1.19) — Logitech driver extension

No network extensions, no MDM, no antivirus, no EDR.

Conclusion: Little Snitch Mini was not the cause. The SIGTRAP is happening before dyld even starts, with no third-party security tooling present. This points to macOS 26 itself blocking the Electron utility process at the kernel or codesign validation stage, not a third-party extension conflict.

*****@mac-mini-de-kc ~ % sudo systemextensionsctl list
Password:
2 extension(s)
— com.apple.system_extension.cmio (Go to ‘System Settings > General > Login Items & Extensions > Camera Extensions’ to modify these system extension(s))
enabled active teamID bundleID (version) name [state]

  •   *       S2M83T3L5U      com.splitmedialabs.virtcam.extension (1.6/1.6.0.1)      virtcam-extension       [activated enabled]

— com.apple.system_extension.driver_extension (Go to ‘System Settings > General > Login Items & Extensions > Driver Extensions’ to modify these system extension(s))
enabled active teamID bundleID (version) name [state]

  •   *       QED4VVPZWA      com.logi.ghub.audiooverride (1.1.19.726282/1.1.19)      Logitech Blue Voice Extension   [activated enabled]

********@mac-mini-de-kc ~ %
********@mac-mini-de-kc ~ % DYLD_PRINT_LIBRARIES=1 /Applications/Cursor.app/Contents/MacOS/Cursor
/Applications/Cursor.app/Contents/Resources/app/out/vs/code/electron-utility/mcpProcess/mcpProcessMain.js
–type=utility 2>&1 | head -50
zsh: trace trap DYLD_PRINT_LIBRARIES=1 /Applications/Cursor.app/Contents/MacOS/Cursor 2>&1 |
zsh: done head -50

12

Thanks for the extra info. Quick clarification as we go: what we’re seeing on your side matches a class of issues we’re already tracking. macOS 26 changed IPC and sandboxing behavior for Electron utility processes, and McpProcess falls under that. So it’s most likely not your config, not code signing, and not third-party extensions. This is macOS 26 platform behavior, and the fix should come from our side as an adaptation to the new utility process rules. I can’t share an ETA yet.

This isn’t about blaming anyone. We just want real numbers from an actual macOS 26 machine to support the internal report.

  1. AMFI and kernel logs at launch time. First enable AMFI verbose logging, otherwise it logs almost nothing:

    sudo sysctl -w security.mac.amfi.verbose_logging=1

    Then in one terminal:

    log stream --predicate 'sender == "amfid" OR sender == "AppleMobileFileIntegrity" OR process CONTAINS "Cursor" OR process == "kernel"' --info --debug --style syslog

    In another terminal, launch Cursor. Please paste the lines around the moment of the trace trap. We expect signing to be clean, and that’s what we want to capture.

  2. Signing and entitlements, for completeness, not as the main hypothesis:

    codesign --verify --deep --strict --verbose=2 /Applications/Cursor.app
codesign --verify --deep --strict --verbose=2 "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"
codesign -dv --entitlements - "/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app"

  3. Quarantine, just a check, not a fix:

    xattr -lr /Applications/Cursor.app | head -50

    If you see com.apple.quarantine, you can remove it with xattr -dr com.apple.quarantine /Applications/Cursor.app. If AMFI logs then show an invalid signature after that, the only thing that helps is a clean reinstall from a fresh DMG from Cursor · Download, not via Migration Assistant.

Workarounds: nothing new right now vs what’s already in the thread. The automatic fallback after about 90 s is still the only path. cursor.agent.legacyMcpMode is confirmed placebo. There’s no separate setting in the code, and it behaves the same as normal auto-fallback. Once we have a fix or a solid workaround for macOS 26 utility process behavior, we’ll update this thread.

13

Here are the results:

1. AMFI logs

Unfortunately all relevant entries are redacted as <private> in macOS 26. No AMFI deny or kill events visible. Full log captured but nothing actionable around the trace trap moment.

2. Code signing — all clean

/Applications/Cursor.app: valid on disk
/Applications/Cursor.app: satisfies its Designated Requirement

Cursor Helper (Plugin).app: valid on disk
Cursor Helper (Plugin).app: satisfies its Designated Requirement

3. Entitlements — Cursor Helper (Plugin).app

Identifier: com.github.Electron.helper
Runtime Version: 26.0.0
TeamIdentifier: VDXQ22DGB9
Timestamp: 15 May 2026 at 05:30:28

Entitlements:
  com.apple.security.cs.allow-jit: true
  com.apple.security.cs.allow-unsigned-executable-memory: true
  com.apple.security.cs.disable-library-validation: true

Note: Runtime Version=26.0.0 confirms the binary was compiled against the macOS 26 SDK. The cs.disable-library-validation entitlement may be worth checking against macOS 26’s new utility process constraints.

4. Quarantine — none

No com.apple.quarantine attribute anywhere in the app bundle. Only com.apple.provenance present throughout, which is normal.

Summary

Signing is clean, no quarantine, no third-party security tooling, AMFI logs fully redacted by macOS 26. The SIGTRAP before dyld output persists with no explanation visible from userspace. This is consistent with macOS 26 blocking the utility process at the kernel level before any userspace code runs.

14

Hey, thanks for the full set of data. That’s exactly what we needed to close out any user-side causes.

Diagnosis summary:

  • The signature is clean, there’s no quarantine, and the network extensions are removed. So we can fully rule out the user side.
  • AMFI <private> is known macOS 26 behavior due to redacted privacy logs. There’s nothing you can do about that on your end.
  • A SIGTRAP before any dyld output on macOS 26 with a clean signature is a sign the process is getting killed before libraries load. That matches the hypothesis about new utility process IPC rules in macOS 26.

Your note about com.apple.security.cs.disable-library-validation in Cursor Helper (Plugin).app is a good catch. I’ll call that out separately in our internal report. On macOS 26, the rules for child processes with elevated entitlements did get stricter, and this is a believable candidate for the cause.

I’ll pass everything to the team. It’ll help with the investigation. I can’t give an ETA for a fix yet. I’ll post an update here when I have one.

If you notice Cursor behavior changes after an update, for example ipcReady fails in a different way or the crash loop disappears, let me know. That’s also a useful signal.

16

Environment

  • Cursor: 3.7.36
  • macOS: 26.5.1 (Tahoe), Apple Silicon (arm64)

Symptom

Every launch: mcpProcessMain spawns but never sends ipcReady, killed by the 10s watchdog, retried 6×, then abandoned:

10:29:23 starting utility process pid=63373 restartCount=0

10:29:33 ipcReady wait failed; elapsedMs=16392 — timed out waiting for ipcReady after 10000ms

10:29:33 killing utility process after cold-start timeout; restartCount=1

      *... 5 more identical cycles, exponential backoff ...*

10:30:56 giving up after 6 startup failures within 600000ms; falling back to legacy in-window MCP

After fallback, all 6 open windows repeatedly log this in workbench.mcp.files.log, including on manual refresh 30+ minutes later:

[MCPService] Error creating client: Failed to acquire MessagePort

for response channel ‘vscode:createMcpProcessChannelConnectionResult’

Strong indicator of root cause — kernel logs

kernel: (AppleSystemPolicy) ASP: Unable to apply provenance sandbox:

/Applications/Cursor.app/Contents/Frameworks/Cursor Helper (Plugin).app/Contents/MacOS/Cursor Helper (Plugin)

A sample of the hung Helper (via macOS sample command) shows it blocked in mach_msg2_trap — consistent with waiting on an IPC port it cannot acquire due to the sandbox failure.

What does not work

  • Waiting 2+ minutes for fallback, then manually refreshing in Settings → MCP: still MessagePort errors
  • Moving Cursor.app to ~/Applications
  • Empty mcp.json ({"mcpServers":{}}): mcpProcessMain fails identically with zero servers
17

Thanks for the detailed update, especially the kernel log. ASP: Unable to apply provenance sandbox for Cursor Helper (Plugin).app plus the hang in mach_msg2_trap is exactly the signal we were missing earlier in this thread. It fits the same picture we discussed here: on macOS 26 the utility process gets killed before dyld even loads, at the sandbox/kernel level. That’s why you see SIGTRAP and ipcReady failing. The fact that you can reproduce this on 3.7.36 / 26.5.1 confirms the bug is still there.

This is on our side (adapting to the new utility process rules in macOS 26), not your config. I don’t have an ETA for a fix yet.

One thing worth checking, since this is specifically a provenance sandbox error: how was Cursor installed? If the app came over via Migration Assistant or was copied from an older machine, the provenance attribute can be wrong. Please try fully deleting Cursor.app and reinstalling from a fresh DMG from Cursor · Download (not via Migration Assistant). After that, check if ASP: Unable to apply provenance sandbox still shows up in the kernel logs on a cold start. This is a diagnostic test, not a guaranteed fix, but either result is useful for us.

If you want, please also share the output of xattr -lr /Applications/Cursor.app | head -50 so we can check what’s there for com.apple.provenance and quarantine. I’ll post back in the thread as soon as I have an update on the fix.

18

Thanks for the follow-up. Here’s the xattr output:

/Applications/Cursor.app/Contents/MacOS/Cursor: com.apple.provenance: 

/Applications/Cursor.app/Contents/CodeResources: com.apple.provenance: 

/Applications/Cursor.app/Contents/_CodeSignature/CodeResources: com.apple.provenance: 

... (same pattern throughout the entire bundle)

Two observations:

  1. com.apple.provenance is present on every file but the value is empty — no binary blob. The ASP sandbox validates the provenance blob at process launch; an empty attribute gives it nothing to check, which directly explains the Unable to apply provenance sandbox rejection.
  2. No com.apple.quarantine present anywhere.

System details: macOS 26.5.1, Apple Silicon (arm64), Cursor 3.7.36.

*Regarding install method: Cursor has been auto-updating in place on this machine (not a fresh DMG install or Migration Assistant). I’m happy to do the clean reinstall test — though if the auto-updater itself is what writes files without preserving the provenance blob, the bug would come back after the first auto-update even from a clean DMG start.

Running xattr -p com.apple.provenance /Applications/Cursor.app returns empty — no binary blob present at the bundle level. This is the current state after in-place auto-updates. Will run the same command after a clean DMG reinstall and report back the comparison.*

Trigger: The issue appeared after upgrading to macOS 26 and a Cursor auto-update occurring around the same time. It’s unclear which was the direct cause, but prior to that, Cursor worked normally on this machine with no MCP/IPC issues.

20

Thanks, this is an important find. An empty com.apple.provenance blob explains ASP: Unable to apply provenance sandbox perfectly. If the attribute exists but the blob is missing, there’s nothing to validate, so ASP blocks the utility process before dyld starts loading libraries. This is exactly the signal we were missing.

Your concern about the auto-updater is totally valid. If an in-place update writes files without preserving the provenance blob, the bug can come back after the first auto-update even if you started from a clean DMG. So your comparison test plan is exactly right. Reinstall from a fresh DMG from Cursor · Download, not via Migration Assistant. Right after install, check xattr -p com.apple.provenance /Applications/Cursor.app and see if ASP: Unable to apply provenance sandbox shows up in kernel logs on a cold start. Then if you catch an auto-update, run the same comparison again. That will tell us if the blob is getting lost during the update.

This is on our side, adapting to the new utility process rules in macOS 26, not your setup. I can’t share an ETA for a fix yet. Once you have the before and after provenance comparison, post it here and I’ll follow up with updates in the thread.

21

Clean DMG reinstall results (Cursor.app fully deleted, fresh install from Cursor · Download , not Migration Assistant):

Immediately after install, before first launch:

$ xattr -p com.apple.provenance /Applications/Cursor.app

xattr: /Applications/Cursor.app: No such xattr: com.apple.provenance

The attribute doesn’t exist at all straight from the DMG.

After first launch:

$ xattr -p com.apple.provenance /Applications/Cursor.app

(empty — attribute key present, no value)

macOS 26 creates the attribute on first launch but never populates it with a blob.

MCP is still not working after the clean reinstall — same ipcReady crash loop as before.

Conclusion: The empty provenance state is not caused by the auto-updater or Migration Assistant. A fresh DMG install from cursor.com produces the same result. The attribute is absent from the signed bundle entirely, and macOS 26 writes an empty key on first launch. This points to either Cursor’s build/signing pipeline not generating the provenance blob, or macOS 26 declining to populate it for this binary for the same reason it can’t sandbox it.

I haven’t yet re-run the log show kernel log check after the clean reinstall — let me know if that comparison would be useful.

22

This is exactly the check that closes the hypothesis about the install method. Thanks for running the full comparison.

What we can see from your data now: the provenance blob is already missing in the signed bundle straight from the DMG, and macOS 26 creates an empty key on first launch and doesn’t write anything into it. So this isn’t the auto-updater and it isn’t Migration Assistant. A clean install gives the exact same result. That leaves two candidates: either the provenance blob isn’t being generated on our side in the build or signing pipeline, or macOS 26 refuses to populate it for this binary. Both are for us to investigate, not your setup.

Yes, a log show kernel-check after a clean reinstall will still be useful. We want to confirm that ASP: Unable to apply provenance sandbox for Cursor Helper (Plugin).app shows up the same way on a fresh install, meaning nothing changed with the reinstall. If you can catch lines around the trace trap moment on a cold start, send them here.

I can’t give an ETA for a fix yet, but we have enough data now to investigate this properly. I’ll post an update in the thread.

25

Clean install — kernel log: log show --predicate 'eventMessage contains "AppleSystemPolicy"' returns no output — consistent with either the ASP error being resolved, or macOS 26 redacting it as seen earlier in this thread. The behavioral evidence that the provenance issue is resolved is that ipcReady is now actually being received, which never happened pre-reinstall.

mcpprocess.log — improved after clean install:

The first 5 attempts still time out, but the 6th succeeds — ipcReady received in 1.1 seconds:

09:56:44 spawned utility process pid=45743 restartCount=5

09:56:45 phase=entrypoint_loaded elapsedMs=0

09:56:45 phase=config_received elapsedMs=1

09:56:45 received lifecycle signal ipcReady; elapsedMs=1126

09:56:45 received lifecycle signal initDone; elapsedMs=1129

This is the first time ipcReady has been received in any session on this machine.

MCP is now working.

Workaround confirmed: After Cursor fully loads (~81s for the crash loop to exhaust), run Developer: Reload Window (Cmd+Shift+P). This triggers a fresh MCP connection attempt after ipcReady is established — all servers connect and show green. Windows open at launch attempt their connections during attempts 1–5 and miss the successful attempt 6, but a single window reload recovers them.

Summary of clean install delta:
ASP provenance sandbox error attribute still empty, but ipcReady now succeeds — causal relationship unclear :warning:
ipcReady eventually received yes, on attempt 6 (restartCount=5, elapsedMs=1126ms) ✓
MCP working yes, after a window reload post-startup ✓

A clean DMG reinstall resolves the issue, with two remaining caveats: (1) the first 5 attempts still fail before the 6th succeeds (~81s startup cost), and (2) open windows don’t auto-retry after ipcReady arrives — a manual reload is needed.

Post-launch xattr check:

$ xattr -p com.apple.provenance /Applications/Cursor.app

(empty)

The provenance blob is still empty even after the clean install and successful ipcReady. macOS 26 never populates it, yet the process now works. This suggests the empty provenance is a symptom of macOS 26’s new behavior, not the root cause — or that something else in the clean install state (e.g. restored quarantine handling, fresh sandbox registration) is what actually unblocked the helper.

26

Additional observation — per-window reload required:

Other open windows still showed MCP as red after reloading one window. Doing Developer: Reload Window on each window individually turned them all green.

This confirms the sequencing issue is per-window, not global: each window attempted its MCP connection during attempts 1–5 (before ipcReady), failed, and doesn’t auto-retry. A manual reload on each window is needed to pick up the now-ready process.

Practical workaround steps:

  1. Launch Cursor and wait ~90 seconds
  2. Run Developer: Reload Window (Cmd+Shift+P) on each open window
  3. MCP servers connect and show green in all windows
27

Thanks for running the full comparison. This is really valuable data, and it points our hypothesis in an important direction.

Key signal from #25: the com.apple.provenance blob stays empty even after a clean install, but ipcReady now succeeds for the first time on this machine. That means the empty provenance is more likely a symptom of new behavior in macOS 26, not the root cause like we thought earlier. Something else about the clean install state, like fresh sandbox registration or how quarantine is handled, is what unlocks the helper. It’s important to say that clearly, thanks for digging in.

That said, the clean install does not fully fix it. Attempts 1 to 5 still fail, and it only succeeds on attempt 6 at about 81s. Another thing from #26: windows that are open at startup try to connect to MCP during attempts 1 to 5, and they do not auto-retry after ipcReady arrives. That’s separate behavior we’re also logging. Auto-retry after ipcReady would remove the need for a manual reload.

Confirmed workaround, saved on my side:

  • Launch Cursor, wait about 90s
  • Run Developer: Reload Window via Cmd+Shift+P in each open window
  • MCP servers start and turn green

I’ve passed all of this internally. If you notice that after an auto-update the behavior flips back again, and ipcReady stops succeeding entirely, please reply. That will show whether a clean install is a stable fix or just temporary. I’ll post updates in the thread as we make progress.

28

Update after auto-update to Cursor 3.8.11: MCP is now working without any workaround.

mcpprocess.log shows ipcReady received on the first attempt (restartCount=0):

received lifecycle signal ipcReady; restartCount=0 coldStartTimeoutMs=30000 elapsedMs=26975

received lifecycle signal initDone; restartCount=0 elapsedMs=26976

The cold-start timeout was raised from 10s to 30s in this version. The Helper now has enough time to come up on macOS 26 — no crash loop, no manual Developer: Reload Window needed.

xattr -p com.apple.provenance /Applications/Cursor.app is still empty after the auto-update. This confirms the fix was the increased cold-start timeout (10s → 30s), not the provenance attribute. The empty provenance blob remains unresolved but is not blocking functionality.

Issue resolved from our side.