[Bug]: Codex CLI has unreadable dark input areas under light themes; OSC 11 reports black

Abierto
  • ¿Algo no está bien?
#3,563 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, typescript
Área
developer-experience

Línea de trabajo

Start by reading the reported computeTheme() handling in frontend/app/view/term/termutil.ts and compare the visible theme background with the value used for OSC 11 replies. Use the attached sanitized report's probe to reproduce the SSH and WSL results, then trace where each query or reply is handled. Done means OSC 10/11 replies match the effective theme after switching light and dark modes, with the connection differences explained or documented.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug triage
Current Behavior

Using Codex CLI in a built-in SSH terminal with a light Wave theme produces a mixed light/dark interface:

  • The surrounding terminal has a light background and dark foreground text.
  • The Codex composer/input area has a near-black background with dark text, making the input prompt extremely difficult to read.
  • User-message areas also appear as dark blocks with low-contrast text, affecting conversation readability.

Selecting a light terminal theme through Wave's UI does not resolve the problem. Disabling WebGL improves separate dim-text rendering artifacts, but the dark Codex composer still reproduces.

Read-only terminal queries show that the SSH terminal reports:

  • Light theme: foreground #292D32, background #000000.
  • Dark theme: foreground #C1C1C1, background #000000.

The light theme's configured background is #F5F3EE, so the reported black background does not match the visible background.

The built-in WSL terminal behaves differently: OSC 10/11 queries receive no replies, while DSR cursor-position queries work. Codex in that WSL terminal does not show the same unreadable black composer.

Explicitly setting a light background with OSC 11 before launching Codex makes the SSH composer/message areas readable. This is only a diagnostic workaround, not a solution supporting normal light/dark theme switching.

No data loss or Codex execution failure has been observed; the impact is readability and usability.

Expected Behavior

With terminal transparency set to zero, the default foreground/background reported through OSC 10/11 should match the effective terminal theme.

Changing between light and dark terminal themes in Wave should update subsequent color-query replies consistently.

Starting Codex CLI normally with codex should produce readable text and input/message backgrounds for the selected theme, without requiring OSC startup commands, wrapper functions, or server-wide shell configuration changes.

Any differences in color-query handling between built-in WSL and SSH connections should be investigated or documented.

Steps To Reproduce

  1. On Windows, open a new built-in SSH terminal connected to a Debian Bash shell.

  2. Set the following Wave options:

    {
  "term:transparency": 0,
  "term:disablewebgl": true
}

  3. Select a light terminal theme. The tested custom theme has:

    • Foreground: #292D32
    • Background: #F5F3EE

  4. Start Codex CLI 0.163.0 normally using codex.

  5. Observe the near-black composer/input background with dark, difficult-to-read text despite the surrounding light terminal background.

  6. Exit Codex and run the read-only OSC/DSR probe included in the attached report.

  7. Observe that OSC 10 reports the light theme foreground, but OSC 11 reports #000000.

  8. Switch the same terminal block to a dark theme and repeat the probe. The foreground reply changes, but the background reply remains black.

  9. For comparison, run the probe in a built-in Ubuntu-22.04 WSL terminal under light and dark themes. DSR replies arrive promptly, but OSC 10/11 return no bytes with either BEL or ST terminators within each two-second window.

Do not run a background-setting wrapper such as codex_light before reproducing. The read-only query reproduction does not require Codex to be running.

Wave Version

0.14.5 (202604161539)

Platform

Windows

OS Version/Distribution

Windows 11 Pro 23H2, build 22631.6199

Architecture

x64

Anything else?

Additional environment details:

  • WSL: 3.0.3.0.
  • WSL kernel: 6.18.54.1-1.
  • WSL distribution: Ubuntu-22.04, WSL 2.
  • System32 conhost.exe file version: 10.0.22621.4745.
    This does not establish which console implementation Wave actually uses.
  • SSH target: Debian, kernel 6.12.101+deb13-amd64, Bash 5.2.37.
  • Codex CLI reports 0.163.0 on both systems; executable/configuration equivalence has not been established.
  • Both shells report TERM=xterm-256color, with COLORTERM and COLORFGBG empty.
  • TERM_PROGRAM is empty in WSL and waveterm in SSH.
  • Setting TERM_PROGRAM=waveterm for the WSL Codex launch did not reproduce the SSH symptom.
  • Setting COLORTERM=truecolor in SSH did not fix the symptom.

Controlled query results:

Connection/theme DSR OSC 10 (BEL and ST) OSC 11 (BEL and ST)
WSL/light ~1 ms reply No reply No reply
WSL/dark ~1 ms reply No reply No reply
SSH/light 3–5 ms reply #292D32 #000000
SSH/dark ~3 ms reply #C1C1C1 #000000

Each query waited approximately two seconds. Each complete probe took approximately 12.3–12.5 seconds. SSH color replies arrived within 2–6 ms.

DSR success does not prove that OSC requests reached Wave's frontend: an intermediate console layer may answer DSR. The location where WSL color queries or replies are lost remains unknown.

A source-analysis lead is Wave's computeTheme() handling in frontend/app/view/term/termutil.ts, reportedly assigning a transparent-black xterm background while returning the visible background separately. This is a hypothesis supported by the observations, not verification of the installed binary.

Separately, disabling WebGL removed black rectangles around SGR dim text. That rendering problem should not be conflated with the OSC background-reporting issue.

The attached sanitized report contains the query probe, measured results, source leads, and remaining questions. It was prepared with AI assistance from user-run tests. No credentials, private addresses, project content, or chat transcripts are included.

wave-osc-color-issue-sanitized.md

Lenguaje dominante
Go
Estrellas
22.7k
Forks
1.2k
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de wavetermdev/waveterm

Todos los issues de wavetermdev/waveterm

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.