Allow text selection on Composer questionnaire options

Ideas Feature Requests
,
1

Feature request for product/service

Chat

Describe the request

The Problem:
Currently, the text inside the Composer and tray multiple-choice options is completely unselectable due to global user-select: none rules. Often, the AI provides an option that is almost exactly what I want, but it needs a slight tweak. Because I cannot highlight and copy the option’s text, I am forced to manually retype the entire suggestion just to modify a few words in my follow-up prompt or the “Other…” field.

The Solution:
Targeting the specific label spans to re-enable text selection allows users to highlight the text without introducing weird visual artifacts when clicking the broader button area.

I am currently using this CSS workaround locally, and it works perfectly:

For workbench.glass.main.css:

.ui-tray-option .ui-tray-option__label {
    user-select: text;
    -webkit-user-select: text;
    width: 100%;
}

For workbench.desktop.main.css:

.composer-questionnaire-toolbar-option-label {
    user-select: text;
    -webkit-user-select: text;
}

Implementing this natively would be a massive quality-of-life improvement for workflows where the AI is on the right track but needs minor steering.

Screenshot / Screen Recording

Questions Selected.png
Questions Selected.png790×339 14.7 KB

Operating System (if it applies)

Linux

5

Hey, thanks for the detailed report, and extra thanks for sharing a working CSS workaround and a screenshot with the option highlighted.

Confirmed. These options are rendered as buttons with user-select: none, so the label isn’t selectable right now. That’s by design for UI chrome elements, not a config bug. A request to make option text selectable is already on our radar as a separate item from the general rule. I can’t share a timeline yet, but the idea makes sense and is well justified.

Your local workaround, setting user-select: text on .ui-tray-option__label and .composer-questionnaire-toolbar-option-label, is a totally valid way to fix this on your side until we add native support.

If there’s an update, I’ll post it in the thread.