TUI: DialogModel is too narrow and truncates model names #47600

Activity

1. github-actions

   assigned

   kommander

   on Sep 6, 2026
2. fede-kamel commented on Sep 22, 2026

   

   fede-kamel

   on Sep 22, 2026

   More actions

   Hit the same thing from the other direction — I filed #50527 for this before spotting that you had already reported it three weeks earlier, so I have closed mine as a duplicate of this one. Adding the detail from it here so nothing is lost:

   Beyond the truncation you describe, the dialog has no way to be expanded on demand: there is no keybinding or action-bar entry that gives /models more of the terminal, so with a large catalog the visible slice stays small no matter how wide the terminal is.

   The width is computed in packages/tui/src/ui/dialog.tsx, where size maps to fixed column counts (medium 60, large 88, xlarge 116). That function already calls useTerminalDimensions() for paddingTop, so the terminal size is in scope at the point the width is decided.

   Two shapes seem plausible, and they are not exclusive:

   1. Make the fixed sizes upper bounds rather than absolutes, so a dialog narrows on a small terminal and grows to its cap on a wide one — fixes the truncation you hit with no new UI.
   2. A general maximize toggle on Dialog, so any dialog can expand to fill the terminal, with DialogModel opting in.

   CONTRIBUTING asks for a design review before UI work, so flagging rather than sending a PR — happy to implement whichever shape the team prefers.
3. fede-kamel commented on Sep 22, 2026

   

   fede-kamel

   on Sep 22, 2026

   More actions

   Following up on my comment above: I've implemented option 2 (a maximize toggle on the shared Dialog) so there's something concrete to look at during review. Not opening a PR until the team is happy with the direction:

   fede-kamel/opencode@dev...fede-kamel:opencode:feat/tui-dialog-maximize

   • The model dialog opens at xlarge (116 cols) instead of medium (60), which on its own fixes the truncation reported here.
   • ctrl+o toggles full terminal width and back; the action bar shows Maximize ctrl+o / Restore ctrl+o.
   • It's registered as model_dialog_maximize in the keybind config, so it can be rebound, and documented in keybinds.mdx.

   I first tried ctrl+shift+m, but most terminals send that as ctrl+m, which is Enter — it would select the highlighted model instead of maximizing. ctrl+o isn't bound anywhere in the TUI.

   Happy to rework it into option 1 (sizes as caps that adapt to the terminal) instead, or both, if that's preferred.
4. fede-kamel

   added a commit that references this issue on Sep 22, 2026

   feat(tui): let the model dialog be maximized

   ...

   c7d2f3f
5. fede-kamel commented on Sep 22, 2026

   

   fede-kamel

   on Sep 22, 2026

   More actions

   Update: this is now in #50532, in its own commit alongside a search-ranking fix for the same dialog, so it can be dropped or reworked without touching that fix.

   Since the branch I linked above, the maximized dialog also grows to the full terminal height: the list was still capped at half the screen, so "maximize" only widened it. On a 42-row terminal it now shows 29 rows instead of 15. Screenshots are in the PR.

   Still very open to a different shape if the team prefers, e.g. sizes that adapt to the terminal instead of a toggle.
6. fede-kamel

   added a commit that references this issue on Sep 25, 2026

   feat(tui): let the model dialog be maximized

   ...

   0fc1510
7. fede-kamel commented on Sep 25, 2026

   

   fede-kamel

   on Sep 25, 2026

   More actions

   Update: I took the maximize change back out of #50532 so that PR is a plain bug fix (search ranking) and doesn't sneak a UI change past design review. The maximize work, including the full-height change, is rebased on current dev and waiting here:

   fede-kamel/opencode@dev...fede-kamel:opencode:feat/tui-dialog-maximize

   It is still the same shape: the model dialog opens at xlarge, and ctrl+o (rebindable as model_dialog_maximize) toggles full width and height. TUI tests, typecheck and prettier pass on it. Happy to open it as a PR, or rework it into sizes that adapt to the terminal, whichever the team prefers.
8. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the report, @hazyhaar! You're asking for the model picker to use more of the terminal's width (or a larger dialog size) on wide terminals, so that long model names aren't cut off.

   The 60-column width is currently the dialog's intended "medium" size, not a bug, so I've marked this as a feature request. Maintainers will consider it.

   On current dev, the footer slot in the model picker only shows "Free" or a favorite marker. If you see wider footers with backend or endpoint info, could you share your opencode --version and whether you're using a plugin or a custom build? That would help explain the 35–45 column footers you describe.
9. hazyhaar commented on Nov 2, 2026

   

   hazyhaar

   on Nov 2, 2026

   Author

   More actions

   Current opencode --version: 1.19.3 (official release binary, no custom build and no TUI or provider plugin; the same behavior is present on current dev at ff90ed9160).

   In the unfiltered grouped view, option.footer is indeed only "Free" or the favorite marker, and the provider name appears as a section header. However, whenever a search query flattens the list, DialogSelect replaces the row's footer with option.category — which is the full provider.<id>.name from a standard opencode.json setup with custom @ai-sdk/openai-compatible providers (in my config, two custom provider display names are 36 and 49 characters long):

   1. packages/tui/src/component/dialog-model.tsx passes flat={true} to DialogSelect, and when connected() is true each main-list model option sets category to the provider display name (provider.name in 1.19.3; provider?.name ?? model.providerID on dev at ff90ed9160, except OpenCode's own free models grouped as "Free" under new-designs).
   2. In packages/tui/src/ui/dialog-select.tsx, typing any search query flips flatten() to true (props.search !== undefined || (props.flat && store.filter.length > 0) on dev, props.flat && store.filter.length > 0 in 1.19.3) and renders footer={flatten() ? (option.searchFooter ?? option.category ?? option.footer) : option.footer} (option.category ?? option.footer in 1.19.3) inside <box flexShrink={0}>.
   3. On current dev (dialog-model.tsx:192-193 at ff90ed9160), search results only clear category and move providerName to inline description when experimental["new-designs"] is enabled; with the default config (!newDesigns()), option.category stays set, so the full provider.name occupies the non-shrinking footer slot.

   Dialog defaults to size="medium" (60 columns in packages/tui/src/ui/dialog.tsx), leaving 48 content columns per row once horizontal insets and the 1-cell gap before footer are subtracted (49 columns without footer). A 35–45 char provider.name in footer therefore leaves only 3–13 columns for model.name (and the 36- and 49-char names in my config leave 12 and 0 columns) before <text flexGrow={1} overflow="hidden" wrapMode="none"> clips it. Even without filtering, model names over 49 chars (or title + inline description in Favorites / Recent and under new-designs search) clip at 60 columns on 120–200 column terminals.

   Opening DialogModel at xlarge (116 columns, 104 content columns) with a maximize toggle as in @fede-kamel's feat/tui-dialog-maximize branch — or adaptive dialog sizing that also raises DialogModel's cap above medium — would resolve this cleanly on wide terminals.