Saving a newly created Markdown file in File Explorer (Cmd+S) causes relaunch crash loop until file is deleted

[marcus-42]

Summary

Saving a newly created Markdown file from Warp's File Explorer with Cmd+S can crash Warp and put it into a relaunch crash loop until the offending .md file is deleted outside Warp.

Problem

In Warp's built-in File Explorer/editor flow, creating a new .md file, pasting valid Markdown content, and saving with Cmd+S causes Warp to become unresponsive and crash. After force quitting and reopening, Warp shows the "unexpectedly quit while reopening windows" prompt and repeatedly crashes again. Reinstalling Warp does not resolve the loop. Deleting that specific .md file from Finder breaks the loop and lets Warp open normally.

Expected behavior

Saving a newly created Markdown file should persist the file and keep Warp responsive. Reopening Warp should restore windows without entering a crash loop.

Actual behavior

Cmd+S in this scenario triggers a crash/hang, then Warp repeatedly crashes on relaunch while reopening windows. The loop only stops after deleting the problematic .md file outside Warp.

Reproduction steps or desired workflow

1. Open a project directory in Warp.
2. In Warp File Explorer, right-click and create a new Markdown (.md) file.
3. Open the new file and paste valid Markdown text.
4. Press Cmd+S to save.
5. Warp becomes unresponsive/crashes.
6. Force quit and relaunch Warp.
7. Warp prompts to reopen previous windows, then crashes again (loop).
8. Delete the newly created .md file in Finder; Warp can then launch normally.

Artifacts

Screenshot 1: macOS dialog shown on relaunch: "The last time you opened Warp, it unexpectedly quit while reopening windows" with options to reopen or not reopen windows.
Paste screenshot 1 here

Crash reports attached/provided:
Crash reports.zip
Observed crash signatures from the provided .ips files include repeated EXC_BAD_ACCESS (SIGSEGV) with KERN_INVALID_ADDRESS, across multiple faulting threads, including one report with CoreFoundation: CF objects must have a non-zero isa.

Warp logs found:
Warp logs.zip

Warp version

v0.2026.04.29.08.57.stable_01

Operating system

macOS 15.6.1 (24G90)

[oz-for-oss]

@marcus-42

Here's what I found while triaging this issue:

The attached crash reports point to Warp's text rendering path after the Markdown file is saved/restored, rather than to the disk write itself. Deleting the offending .md file breaking the loop is consistent with Warp reopening and re-rendering that persisted file on launch.

I have a few follow-up questions before I can narrow this down:

1. Can you attach the exact Markdown file/content that triggers the crash, or a redacted minimal version that still reproduces it?
2. Does the same File Explorer create/edit/Cmd+S flow crash with a tiny file such as # test, or only with the original pasted Markdown?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that saving and then re-rendering/restoring a newly created Markdown file from File Explorer appears to trigger a macOS text-layout crash loop..

Triage summary

This is a macOS crash report for the File Explorer → new Markdown file → raw/editor save/render flow. The attached logs show File Tree new-file creation, Markdown raw/rendered mode changes, and CodeViewAction::SaveFile immediately before one of the attached crashes. The relaunch loop is consistent with Warp restoring a persisted local Markdown/code pane and re-rendering the same file on startup.

Evidence

• Four attached .ips reports are EXC_BAD_ACCESS (SIGSEGV) crashes on Stable 0.2026.04.29.08.57.01 / macOS 15.6.1.
• The faulting stacks consistently include CFAttributedStringSetAttribute → warpui::platform::mac::text_layout::create_attributed_string → warpui_core::text_layout::LayoutCache::layout_text → warp_editor::content::edit::layout_text_block.
• crates/warp_files/src/lib.rs saves via async async_fs::write, but the crash stacks point to text layout/rendering after save, not the write itself.
• File and code/notebook panes persist local paths through app/src/pane_group/pane/file_pane.rs, app/src/pane_group/pane/code_pane.rs, and app/src/persistence/sqlite.rs, which explains why reopening windows can re-trigger the crash until the offending Markdown file is removed.

Likely area

The initial UI surface is Project Explorer/File Tree, but the crash owner is likely shared Markdown/editor rendering on macOS, especially the CoreText attributed-string path and editor layout style ranges.

Duplicate scan

A related open issue, #8396, also describes a Markdown file causing a crash loop, but it involves a large Markdown file with embedded images and CPU spike. I did not find two existing issues with the same File Explorer-created Markdown save/relaunch-crash pattern, so this should not be marked duplicate yet.

Question reasoning

1. Can you attach the exact Markdown file/content that triggers the crash, or a redacted minimal version that still reproduces it? — The crash appears content- or style-range-specific in macOS text layout; maintainers need the triggering Markdown to reproduce and narrow the invalid attributed-string/style-run state.
2. Does the same File Explorer create/edit/Cmd+S flow crash with a tiny file such as # test, or only with the original pasted Markdown? — This separates a general new-file save/regression from a Markdown-content-specific rendering crash.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz