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

Aberta
  • Algo errado?
#3,563 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
go, typescript
Domínio
developer-experience

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Go
Estrelas
22.7k
Forks
1.2k
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de wavetermdev/waveterm

Todas as issues de wavetermdev/waveterm

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.