v1.4.0 crashes with CheckedContinuation misuse on macOS 26.2 (25C56)

[narangproduct-cmyk]

Environment

• iMCP version: 1.4.0 (Build 10)
• macOS: 26.2 (25C56) Tahoe
• Hardware: Mac17,2 (Apple Silicon, arm64)
• Installation: Homebrew cask (brew install --cask mattt/tap/iMCP)

Description

iMCP v1.4.0 crashes immediately upon receiving an MCP client connection via imcp-server. The crash occurs in CheckedContinuation.resume(throwing:) with SWIFT TASK CONTINUATION MISUSE, identical to the issue fixed in PR #112.

This appears to be a regression or incomplete fix -- the same crash pattern occurs on the com.apple.root.user-initiated-qos.cooperative queue.

Reproduction Steps

1. Install iMCP v1.4.0 via Homebrew cask
2. Launch iMCP.app (menu bar icon appears)
3. Run: echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"claude-code","version":"1.0.0"}}}' | /Applications/iMCP.app/Contents/MacOS/imcp-server
4. iMCP.app shows client approval dialog → click "Allow"
5. iMCP.app crashes immediately after approval

Observed Behavior

• imcp-server outputs repeated connectionClosed errors
• System log shows: Fatal error: SWIFT TASK CONTINUATION MISUSE: connect() tried to resume its continuation more than once
• 4 crash reports generated within 8 minutes

Crash Log (Thread 3, faulting thread)

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Queue: com.apple.root.user-initiated-qos.cooperative

Thread 3 Crashed:
0  libswiftCore.dylib  _assertionFailure(_:_:file:line:flags:)
1  libswift_Concurrency.dylib  CheckedContinuation.resume(throwing:)
2  iMCP  (offset 899416)
3  iMCP  (offset 108941)
4  iMCP  (offset 877321)
5  iMCP  (offset 108941)
6  libswift_Concurrency.dylib  completeTaskWithClosure

Related Issues

• App crashes with "CheckedContinuation resumed multiple times" after running for ~12 minutes #111 (closed with v1.4.0 -- same crash pattern)
• Fix crash caused by calling checked continuation multiple times #112 (PR fix for continuation misuse -- merged in v1.4.0)
• bug: crash immediately on launch with error -10810 on macOS 26.1 #113 (closed with v1.4.0 -- macOS 26.1 crash)

Notes

This may be specific to macOS 26.2 (Tahoe). The previous reporters were on macOS 26.2 beta and macOS 26.1. The PR #112 fix addresses continuation misuse in CLI/main.swift, Capture.swift, and ServerController.swift, but the crash stack suggests an unpatched code path in the main app binary.

[DigitallyDemented]

Same issue on macOS 26.2 (25C56)

Crash Report

• App: iMCP v1.4.0 (build 10)
• OS: macOS 26.2 (25C56)
• Hardware: Mac16,7 (ARM-64)
• Date: 2026-02-01 01:03:50.4237 -0600

Exception

Type: EXC_BREAKPOINT
Signal: SIGTRAP
Codes: 0x0000000000000001, 0x0000000198a099d4

Termination

Trace/BPT trap: 5

Faulting Thread Stack

assertionFailure(:_:file:line🎏) + 176
CheckedContinuation.resume(throwing:) + 324
[iMCP internal frames]
completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

Same behavior as described: crashes immediately when Claude Code connects after approving in UI dialog.

[madisonrickert]

I'm getting the issue on macOS 26.3 as well.

Version:             1.4.0 (10)
Hardware Model:      MacBookPro17,1
OS Version:          macOS 26.3 (25D125)
Date/Time:           2026-02-25 07:50:32.3734 -0800

...

Triggered by Thread: 10, Dispatch Queue: com.apple.root.user-initiated-qos.cooperative

...

Exception Type:    EXC_BREAKPOINT (SIGTRAP)
Exception Codes:   0x0000000000000001, 0x00000001a025b9d4

...

Thread 10 Crashed::  Dispatch queue: com.apple.root.user-initiated-qos.cooperative
0   libswiftCore.dylib            	       0x1a025b9d4 _assertionFailure(_:_:file:line:flags:) + 176
1   libswift_Concurrency.dylib    	       0x28c00aa34 CheckedContinuation.resume(throwing:) + 324
2   iMCP                          	       0x10462f958 0x104554000 + 899416
3   iMCP                          	       0x10456e98d 0x104554000 + 108941
4   iMCP                          	       0x10462a309 0x104554000 + 877321
5   iMCP                          	       0x10456e98d 0x104554000 + 108941
6   libswift_Concurrency.dylib    	       0x28c07431d completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

[JaviOFC]

Confirming on macOS 26.4 (25E246) — and a working build-from-source workaround

Still happening on the latest macOS:

• iMCP 1.4.0 (build 10)
• macOS 26.4 (25E246)
• MacBookPro18,2 (Apple Silicon)
• 11 crash reports from Mar 22–28, all identical signature

Crashes within 3 seconds every launch. Identical stack: _assertionFailure → CheckedContinuation.resume(throwing:) on com.apple.root.user-initiated-qos.cooperative. Caught live on stderr:

SWIFT TASK CONTINUATION MISUSE: connect() leaked its continuation without resuming it.
SWIFT TASK CONTINUATION MISUSE: connect() leaked its continuation without resuming it.
SWIFT TASK CONTINUATION MISUSE: connect() leaked its continuation without resuming it.
SWIFT TASK CONTINUATION MISUSE: connect() leaked its continuation without resuming it.
Fatal error: SWIFT TASK CONTINUATION MISUSE: connect() tried to resume its continuation
more than once, throwing [-32603] Internal error: Connection cancelled!

Claude Desktop was running, which triggers the connection storm.

Build-from-source workaround (requires Xcode)

PR #149 (fix/bump-swift-sdk-continuation-crash) disables reconnection/heartbeats for server-accepted connections, which eliminates the race. However, it won't compile under Xcode 26.4 because Swift 6 strict concurrency catches the data races in the MCP SDK's NetworkTransport.swift as errors.

The fix: patch two lines in the resolved SDK source after the first build resolves packages:

// In SourcePackages/checkouts/swift-sdk/Sources/MCP/Base/Transports/NetworkTransport.swift

// Line ~515: change
var sendContinuationResumed = false
// to
nonisolated(unsafe) var sendContinuationResumed = false

// Line ~750: change
var receiveContinuationResumed = false
// to
nonisolated(unsafe) var receiveContinuationResumed = false

Then build:

git clone --depth 1 -b fix/bump-swift-sdk-continuation-crash https://github.com/peters438/iMCP.git
cd iMCP
xcodebuild -scheme iMCP -configuration Debug -derivedDataPath ./build \
  CODE_SIGN_IDENTITY="-" CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO
# Apply the two patches above to ./build/SourcePackages/checkouts/swift-sdk/...
# Then rebuild. Copy ./build/Build/Products/Debug/iMCP.app to /Applications/

Produces a working debug build. Tested stable for 30+ seconds (original crashed in ~3s every time) and has been running without issues since.

The nonisolated(unsafe) annotation is a pragmatic concession — the boolean guards are technically data races, but PR #149's disabling of reconnection eliminates the concurrent access pattern that triggers the double-resume at runtime.

Ideally the underlying MCP Swift SDK (modelcontextprotocol/swift-sdk) would replace the CheckedContinuation + boolean guard pattern with AsyncStream, which is what the newer SDK revisions do. PR #151 takes a similar approach from the iMCP side by disabling reconnection.