Bug: Composer input overflow with long unbroken string causes layout shift and send button misalignment

[KafkaeskZ]

Describe the bug

When typing or pasting a long unbroken string (no spaces, e.g., aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa... or a long base64 token) in the Composer input box, the text overflows the input area instead of wrapping. This causes the flex container to expand, shifting the entire composer layout and misaligning the send button relative to the input.

To Reproduce

1. Open Continue Composer in VS Code
2. Type or paste a long string without spaces (e.g., 100+ a characters) into the input box
3. Observe that the text extends beyond the input box boundary
4. The composer panel shifts horizontally, and the send button drifts out of alignment

Expected behavior

• Long unbroken strings should wrap inside the input box
• The composer layout should remain stable regardless of input content
• The send button should stay in its normal position

Screenshots / Recordings

N/A — easily reproducible with any long no-space string.

Environment info

• Continue version: latest (observed in recent versions)
• IDE: VS Code
• OS: all (cross-platform CSS issue)

Root cause

The Composer uses TipTap (TipTapEditor.tsx + TipTapEditor.css) as its input component.

1. No text wrapping fallback — The .tiptap styles in TipTapEditor.css lack overflow-wrap: break-word / word-break: break-word. By default, the browser does not break unbroken strings, so they overflow the contenteditable div.
2. No min-width constraint on flex item — The input wrapper or its flex container lacks min-width: 0, so the flex item's default min-width: auto prevents the container from shrinking below the content width. This propagates the overflow outward, shifting the layout.

Suggested fix

In gui/src/components/mainInput/TipTapEditor/TipTapEditor.css, add to the .tiptap class:

.tiptap {
  overflow-wrap: break-word;
  word-break: break-word;
}

And on the flex container or input wrapper in ContinueInputBox.tsx (or equivalent), add min-width: 0 to the appropriate flex child to allow proper shrinking.

Additional context

This is a classic CSS flexbox overflow issue. The fix is minimal, backwards-compatible, and has no side effects on normal input behavior (spaces still wrap as before; only unbroken strings are affected).

[shubhook]

Hi, I'd like to work on this. I've identified the root cause: missing overflow-wrap: break-word in TipTapEditor.css and min-width: 0 on the flex container in ContinueInputBox.tsx. Will open a PR shortly.