Fix char-boundary panic and non-prefix rewrite corruption in AI code streaming (APP-5288) - #14936

Description

Fixes a client panic reported via a crash-report bot post and Slack thread: panic: byte index is not a char boundary while streaming AI code (APP-5288).

Root cause: AI fenced-code streaming (AIBlock::handle_code_section_stream_update in block.rs, duplicated in block/cli.rs) stored the previously-rendered code length as a raw usize (EmbeddedCodeEditorView::length) and sliced the next full code string at that offset with no boundary check:

view.append_at_end(&code[embedded_view.length..], ctx);

When the stored length lands inside a multi-byte UTF-8 codepoint — e.g. a non-prefix rewrite from the server, or a code-fence edge — this slice panics with exactly the reported message.

A secondary instance of the same bug class: RequestedCommand::apply_streamed_update's shrink path did an unguarded self.command_text.truncate(command.len()). Its grow path was already guarded (APP-1956) — mirrored that pattern for the shrink direction too.

Revision (this push): an adversarial review of the first pass found that a boundary-only check (checking only that the split offset was a valid UTF-8 char boundary) doesn't verify the new value actually extends the old one. A boundary-aligned but non-prefix rewrite — e.g. rendered "abc" followed by "XYZq" (offset 3 is a valid boundary in both) — would append "q" and silently corrupt the buffer to "abcq" instead of resetting to "XYZq". Same-length rewrites were also missed entirely (an Ordering::Equal short-circuited to a no-op). Fixed by comparing byte contents (strip_prefix/starts_with), not just byte lengths/boundaries, for grow, shrink, and equal-length cases — this is inherently char-boundary-safe too, since str prefix/equality comparisons never panic regardless of alignment.

Changes

• app/src/ai/blocklist/block.rs: streamed_code_update now takes the previous value (not just its length) and returns Append/Truncate/Reset/NoOp based on content, not length. EmbeddedCodeEditorView now stores rendered_code: String instead of length: usize. apply_streamed_code_update applies the decision to a CodeEditorView, resetting via CodeEditorView::reset on any non-prefix-stable rewrite.
• app/src/ai/blocklist/block/cli.rs: reuses the same shared helper (no duplicated logic).
• app/src/ai/blocklist/inline_action/requested_command.rs: apply_streamed_update now computes the StreamedCodeUpdate decision once (via the shared streamed_code_update, made pub(super)) and applies it identically to both command_text and the editor via the new apply_streamed_command_editor_update, instead of the editor half independently re-deriving its own update from a length-only comparison against its current content (the same bug class, just for the editor).
• Kept the change scoped to the boundary/content guard itself; did not migrate the surrounding code to the repo's ByteOffset/CharOffset newtypes.

Linked Issue

Linear: APP-5288

Testing

• app/src/ai/blocklist/block_tests.rs:
  • Pure streamed_code_update cases: append/grow, multi-byte append, boundary-aligned non-prefix grow reset (the "abc"→"XYZq" case), non-prefix grow with multi-byte content, valid shrink, non-prefix shrink reset, equal-length rewrite reset, no-op.
  • Real-CodeEditorView cases (constructed via the same singleton-mock pattern as code::editor::view::view_tests) exercising the actual apply_streamed_code_update function used by AIBlock/CLISubagentView: append-then-reset-on-non-prefix-rewrite of an already-populated editor, truncate-on-valid-shrink, reset-on-non-prefix-shrink. These assert the buffer's real rendered text, not just the decision enum.
• app/src/ai/blocklist/inline_action/requested_command_tests.rs: real-CodeEditorView cases exercising apply_streamed_command_editor_update (the exact function RequestedCommandView::apply_streamed_update uses to sync its editor): append, reset-on-non-prefix-rewrite of an existing editor, truncate-on-valid-shrink, no-op.
  • Note on AIBlock/CLISubagentView/RequestedCommandView themselves: constructing these directly in a unit test would require read access to several private TerminalView fields (e.g. ai_action_model, cli_subagent_controller) that aren't visible outside crate::terminal::view's own module tree without adding new pub(crate) test accessors to that large, sensitive file. I judged that out of scope for this fix and instead tested the exact shared functions these types call, against a real CodeEditorView — the closest practical "real state transition," and enough to prove the buffer itself ends up correct.
• Verified regression-test validity: reverted to the pre-fix logic locally and confirmed the exact "byte index is not a char boundary" panic reproduces with the vulnerable slicing pattern.
• ./script/format — clean.
• cargo clippy -p warp --lib --tests -- -D warnings — clean (fixed one manual_strip clippy finding from the content-comparison rewrite). --all-features hits pre-existing, unrelated clippy failures in warp_completer, confirmed present on master without this change.
• cargo test -p warp --lib for ai::blocklist::block (115 tests) and ai::blocklist::inline_action::requested_command (16 tests) — all pass. Full ai::blocklist:: suite passes (753 tests); one secret_redaction test flakes intermittently under parallel execution and is reproducible as pre-existing flakiness on master alone, unrelated to this change.
• Visual proof: not captured. Computer use is unavailable in this environment. Reproducing this specific defect (a boundary-aligned, non-prefix streamed code/command rewrite) end-to-end in the live GUI would require either computer use, or standing up a new crates/integration real-display GPU test that mocks a non-prefix code stream through the actual AI conversation pipeline — a disproportionate new-test-infrastructure investment for a fix whose only visible effect, in the rare case it's hit, is that the block now shows the correct final text instead of corrupted text or a crash. Flagging this explicitly rather than skipping it silently.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Conversation: https://staging.warp.dev/conversation/5c0e523f-9044-4c99-9d26-b18751eb982f
Run: https://oz.staging.warp.dev/runs/019ff0fd-9630-7070-adcf-9744f5f41308

This PR was generated with Oz.