Crash on terminal resize with CJK (wide) characters in the prompt

[Im-Tae]

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
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Warp crashes (the whole app quits) when the terminal contains wide (full-width, cell-width 2) characters — e.g. a directory named in Korean (한글) shown in the shell prompt — and the terminal grid is resized (window/pane layout change, or prompt redraw while typing).

The crash is a Rust panic that aborts the process (SIGABRT / abort() called). From the macOS crash report, the panicking frame is:

warp::terminal::model::grid::resize::InitialCursorState::into_content_offset
  → core::result::unwrap_failed   (.expect("should have a content offset for point"))

Call chain:
TerminalView::resize_internal → TerminalModel::resize → BlockList::resize → GridHandler::resize → resize_storage → InitialCursorState::into_content_offset → panic

Root cause (preliminary): the cursor point computed against the live grid in InitialCursorState::new does not map to a valid content offset in flat_storage when the row contains wide characters; content_offset_at_point(point) returns Err (column exceeds content / wide-char spacer case) and the .expect() aborts instead of degrading gracefully. The content_offset_at_point doc comment itself lists WIDE_CHAR_SPACER / LEADING_WIDE_CHAR_SPACER cells as untested cases.

To reproduce

1. Create a directory with a Korean name, e.g. mkdir 한글폴더
2. cd 한글폴더 so the prompt shows the wide characters
3. Use the terminal / type a command / resize the window or split a pane (anything that triggers a grid resize)
4. Warp crashes and quits

(Only Korean was tested; any wide/CJK character is expected to trigger it.)

Expected behavior

The terminal handles wide characters during resize without crashing; the cursor is placed at a reasonable position.

Screenshots, videos, and logs

macOS crash report attached (EXC_CRASH / SIGABRT, abort() called). Key frame:
warp::terminal::model::grid::resize::InitialCursorState::into_content_offset + unwrap_failed.

Operating system (OS)

macOS

Operating system and version

macOS 26.4 (25E246) — Apple M4 Pro (Mac16,8)

Shell Version

No response

Current Warp version

0.2026.06.17.09.49.02 (stable)

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

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.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

No response

[oz-for-oss]

@Im-Tae

This issue appears to overlap with existing issues:

• Repeated SIGABRT crash in GridHandler::resize (InitialCursorState::into_content_offset unwrap panic) #9013 — Repeated SIGABRT crash in GridHandler::resize (InitialCursorState::into_content_offset unwrap panic)
• Crash (SIGABRT) during window drag-resize: InitialCursorState::into_content_offset unwrap panic #8881 — Crash (SIGABRT) during window drag-resize: InitialCursorState::into_content_offset unwrap panic
• Warp Preview can crash in RowIterator::next after clear resize truncates a wide-character spacer #12243 — Warp Preview can crash in RowIterator::next after clear resize truncates a wide-character spacer

If this report is meaningfully different, please comment with the additional context or distinguishing behavior so a maintainer can review it. Otherwise, a maintainer may close it as a duplicate after review.

Maintainer details

I concluded that warp crashes during terminal resize when wide/CJK prompt content causes the grid resize path to unwrap an invalid flat-storage content offset..

Duplicate reasoning

• Repeated SIGABRT crash in GridHandler::resize (InitialCursorState::into_content_offset unwrap panic) #9013: Same terminal resize crash path and same InitialCursorState::into_content_offset unwrap panic, with repeated macOS SIGABRT crashes during layout/resize events.
• Crash (SIGABRT) during window drag-resize: InitialCursorState::into_content_offset unwrap panic #8881: Same resize-triggered SIGABRT and identical InitialCursorState::into_content_offset unwrap failure in the reported call chain.
• Warp Preview can crash in RowIterator::next after clear resize truncates a wide-character spacer #12243: Same broad terminal-grid resize crash family involving wide-character spacer invariants, although the final panic frame differs from this report.

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

Powered by Oz

[Im-Tae]

@oss-maintainers

This is an actionable crash with a clear root cause and a fix
ready (defensive handling in app/src/terminal/model/grid/resize.rs + a
regression guard test). Could you please triage this to ready-to-implement so
I can open the PR? Happy to adjust the approach based on your guidance.

[Im-Tae]

Thanks @oz-for-oss. Agreed — this is the same crash as #9013 and #8881
(the InitialCursorState::into_content_offset unwrap panic during resize).
A Korean directory name in the prompt is just one trigger for that same panic.
I'll open a fix PR linked to #9013 and #8881, so feel free to close this as a
duplicate. I'll add my concrete reproduction to #9013 for the record.

[kevinchevalier]

Thanks for the report!

[vorporeal]

Hey @Im-Tae - if you have a reliable repro and put together a PR fixing it, feel free to add me as the reviewer! I wrote the relevant code, so would be the best person on our end to take a look.