Summary

In interactive selection prompts (notably the ask_user_question tool), the currently focused/selected option row is indicated by a change of text color only — there is no background highlight, and the selected text color is nearly identical to the normal text color. The selected row is therefore effectively indistinguishable from the others.

There is no supported setting to raise this contrast ( theme only accepts dark/ light/ auto, and there is no custom-theme mechanism), so the only workaround is patching the bundled dist/cli.mjs — which has to be re-done on every release, because the minified identifiers change each version.

Impact

• Hard to tell which option is about to be chosen; error-prone when several options are present.
• Accessibility problem for low-vision users.

Suggested fixes (any one would help)

1. Default behavior — apply HIGHLIGHT_BAR_BG as the background of the selected option row with a contrasting foreground, matching the existing bar style.
2. Make it configurable — expose the theme palette to users so this can be tuned without patching, e.g. a ~/.commandcode/theme.json overriding tokens, or settings keys such as theme.highlightBarBg / theme.selectedText.
3. At minimum — increase the difference between the selected and idle text colors so it reaches a ≥3:1 ratio.

Why a supported setting matters (patch burden)

Because there is no setting, the only local fix is to rewrite the bundled dist/cli.mjs. The minified identifiers for these components changed on every recent release:

| Version | OverlayOptionText | OverlayCaret | OverlayActiveTick | MultiSelectCheckbox |

| 1.72.4 | i_ | a_ | c_ | M_ |

| 1.74.0 | f_ | h_ | S_ | N_ |

| 1.74.1 | w_ | S_ | k_ | U_ |

So any external patch breaks after each update and must be re-derived from the new bundle. A supported theming hook (option 2) would remove this maintenance entirely.

Workaround currently used

An in-memory ESM loader that injects a background highlight into the selected option rows (without modifying the installed, root-owned files). It becomes a no-op whenever the markers no longer match — which is exactly the maintenance cost described above.

Attachments

Captured from live terminals (two runs of 1.74.1, light theme, same prompt), pane captured with true-color SGR and re-rendered at those exact colors; terminal background #F5F4F4 sampled from the real screen.

commandcode-contrast-compare.png — side by side, default vs patched (Opsi 1 and Opsi 2 focused):

• Left column = default build: the focused row’s text is #E4CCFF on the light background — nearly invisible (1.33:1); the non-focused rows are clearly readable.
• Right column = with a local patch: the focused row gets a filled highlight bar with white bold text, unmistakably different from the other rows.

commandcode-contrast-demo.png — the patched rendering on its own (option 1 and option 2 focused).

Expected Behavior

The focused/selected option row should be clearly distinguishable — e.g. a filled background bar (using HIGHLIGHT_BAR_BG) plus bold text, consistent with the highlight bar already used elsewhere.

Actual Behavior

The option row is rendered by the overlay components (from the bundled source):

OverlayOptionText → color = isSelected ? ACCENT : isActive ? GREEN : WHITE, bold = isSelected && isLightTheme(), no backgroundColor.
OverlayCaret → color = isSelected ? ACCENT : GRAY.

Measured WCAG contrast ratio (relative luminance), from the actual rendered output (captured from a live terminal on 1.74.1, theme light, terminal background #F5F4F4):

Theme Focused row text Other rows text Focused vs other rows
dark#E4CCFF#E5E5E5 1.16:1
light#E4CCFF (see note)#111827 1.33:1

Both are far below the 3:1 minimum typically required to distinguish a UI state.

Note on the light theme: the focused row is actually rendered in #E4CCFF (the dark-theme ACCENT), not the light ACCENT #5B21B6 — because the overlay text colors are snapshotted from the palette at module load and are not refreshed when the theme changes. On the light background (#F5F4F4) that is 1.33:1, so the focused row is less legible than the non-focused rows (#111827 on #F5F4F4 ≈ 16.16:1) — the selection is nearly invisible.

The theme already defines HIGHLIGHT_BAR_BG (dark #2D2B55, light #DDD6FE), and the UI uses a filled highlight bar elsewhere (e.g. some select bars), but it is not applied to these option rows. In the light theme that token is itself only 1.33:1 against the background (#DDD6FE vs #fafafa).

Steps to reproduce the issue

1. cmd config set theme dark --scope user (repeat with light).
2. Trigger any selection prompt — e.g. an ask_user_question with 2–4 options.
3. Move the selection with the arrow keys.

Command Code Version

1.74.1 (also observed on 1.72.4 and 1.74.0)

Operating System

Linux

Terminal/IDE

foot

Shell

bash

Session file (optional)

No response

Fix prompt (optional)

No response

Additional context

No response