Crash (SIGSEGV) in layout_edit_delta when opening .md files on macOS 26.2

[pmoorman]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there

Describe the bug

Warp crashes with EXC_BAD_ACCESS (SIGSEGV) approximately 2–8 seconds after launch. The crash occurs in the editor layout rendering pipeline. The issue is reproducible and appears to be triggered by opening .md (Markdown) files.

Crash signature:

Exception Type:    EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS
Application Specific Information: *** CFGetRetainCount() called with NULL ***

Faulting code path (from crash report):

warp_editor::content::edit::EditDelta::layout_delta
→ warp_editor::render::model::RenderState::layout_edit_delta
→ warp_editor::render::model::RenderState::handle_layout_action

The crash happens during parallel layout computation using rayon. A null pointer is passed to CFGetRetainCount(), causing the segfault. The faulting address falls in a gap between thread stacks (between a thread stack and a Stack Guard region).

Workaround: Deleting the session restoration database resolves the crash temporarily, but it recurs when opening .md files again:

rm -f "$HOME/Library/Group Containers/2BBY89MBSN.dev.warp/Library/Application Support/dev.warp.Warp-Stable/warp.sqlite"

This is similar to #7515, but with a different crash signature (SIGSEGV in layout_edit_delta rather than SIGABRT in resize_storage).

To reproduce

1. Open Warp on macOS 26.2
2. Open/view a .md file (e.g., from the Downloads folder)
3. Warp crashes within seconds
4. On subsequent launches, Warp crashes immediately (~2s after launch) due to corrupted session restoration state
5. Deleting warp.sqlite (see workaround above) allows Warp to launch again, but the crash recurs when opening another .md file

Expected behavior

Warp should open and render .md files without crashing.

Screenshots, videos, and logs

Crash report excerpt (Thread 0 — main thread):

Thread 0:: main Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          __psynch_cvwait + 8
1   libsystem_pthread.dylib         _pthread_cond_wait + 984
2   stable                          rayon_core::latch::LockLatch::wait_and_reset + 184
...
9   stable                          warp_editor::content::edit::EditDelta::layout_delta + 232
10  stable                          warp_editor::render::model::RenderState::layout_edit_delta + 360
11  stable                          warp_editor::render::model::RenderState::handle_layout_action + 1476
12  stable                          ModelContext<RenderState>::spawn_stream_local + 240
13  stable                          AppContext::relay_task_output + 708

VM Region Info:

0x171cf6874 is not in any region.
Stack                       171be8000-171c70000    [  544K] rw-/rwx SM=PRV  thread 21
--->  GAP OF 0x8c000 BYTES
Stack Guard                 171cfc000-171d00000    [   16K] ---/rwx SM=NUL

Operating system (OS)

macOS

Operating system and version

macOS 26.2 (25C56)

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.02.25.08.24.stable_01

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

2026-02-24

Additional context

• Hardware: MacBookPro18,3 (Apple Silicon, ARM-64)
• The crash is 100% reproducible
• Clearing all Warp data (Application Support, Preferences, Caches, Saved Application State, ~/.warp/) does not fix the issue — only deleting warp.sqlite from Group Containers works
• The crash persists across multiple launches with identical stack traces (only addresses differ due to ASLR)
• Related issue: Warp crashes on macOS 26.0 immediately after launch #7515 (similar macOS 26 launch crash, different code path)

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

[vorporeal]

@pmoorman thanks for the report!

can you provide the entire crash log file (not just snippets)? the crash here is not on the main thread, and seeing the state of all threads would be helpful in understanding what's going on.

does this happen for you with any markdown file? or just specific ones? if the latter, and if this is a markdown file you're willing to share (even if privately over email - my email is my first name at warp dot dev), that might help us reproduce the crash.