[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.