Multi-line paste is split into multiple messages and sent separately

[panchinpeng]

Description

When pasting multi-line text into the OpenCode input field in Visual Studio Code (via OpenCode extension), the content is incorrectly split and submitted as multiple messages instead of a single block.

Steps to Reproduce
Open VS Code with OpenCode extension
Focus on the OpenCode input box

Copy a multi-line text, e.g.:
line 1
line 2
line 3

Paste it into the input field
Observe the behavior

Actual Behavior
The pasted text is split into multiple parts
Each line (or each \n) triggers a separate submit event
Result: multiple messages are sent instead of one

Expected Behavior
Multi-line pasted content should be treated as a single input block
No automatic submission should occur on paste
Only explicit submit action (e.g. Ctrl+Enter / Enter depending on config) should send the message

Plugins

No response

OpenCode version

0.0.13

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

windows 10

Terminal

No response

[desideratum]

Cross-referencing #24735: the same symptom reproduces in the OpenCode TUI on macOS / iTerm2 with version 1.14.28. Pasting a multi-paragraph block causes each paragraph to be submitted as a separate message rather than received as a single input.

Different surface (terminal TUI vs. VS Code extension webview), but the failure mode is identical: the input handler is treating embedded newlines as submit events instead of buffering the paste atomically. This suggests the defect is not specific to one frontend's input layer.

Reproduction in the TUI uses the canonical Lorem Ipsum block from the original (now-closed) #3927 report. Screenshot and full environment details are in the linked issue.

[ruslanguns]

Cross-referencing #24735: the same symptom reproduces in the OpenCode TUI on macOS / iTerm2 with version 1.14.28. Pasting a multi-paragraph block causes each paragraph to be submitted as a separate message rather than received as a single input.

Different surface (terminal TUI vs. VS Code extension webview), but the failure mode is identical: the input handler is treating embedded newlines as submit events instead of buffering the paste atomically. This suggests the defect is not specific to one frontend's input layer.

Reproduction in the TUI uses the canonical Lorem Ipsum block from the original (now-closed) #3927 report. Screenshot and full environment details are in the linked issue.

yes i can confirm that it is happening in MacOS with iTerm2 on 1.14.28 - any updates or work arounds suggested?