Skip to content

v0.1.2 - Readable terminal input across themes

Latest
Latest

Choose a tag to compare

View all tags
@DarranLiu DarranLiu released this 23 Sep 13:34
v0.1.2
a3cbfad

v0.1.2: Readable Terminal Input in Dark and Light Mode

English

What was wrong?

A user reported that the page was dark, but the Codex input area had a pale background and almost invisible pale text. We reproduced the same failure with the shipped frontend: text at RGB (228, 228, 228) was drawn on a background at RGB (238, 238, 238).

Terminal applications can draw their own backgrounds. Some also cache colors discovered at startup. Changing the browser theme changes its default text color, but cannot guarantee that a running program recomputes its background. The old renderer left low-contrast combinations untouched.

What changed?

  • Terminal text now uses xterm's built-in minimum contrast adjustment, with a 4.5:1 target for ordinary text. This covers both indexed and truecolor output, including light text on light backgrounds and dark text on dark backgrounds.
  • System light/dark changes update the page and every open pane when there is no manual preference. A manual choice takes precedence.
  • A theme choice in one browser tab updates other tabs on the same origin. Invalid saved values fall back to the system theme.
  • The frontend script URL changed so a reload picks up the fix.

The program's explicit background colors are preserved. An existing pale input block can remain pale, but its ordinary text becomes readable. Dim placeholder text keeps xterm's intentionally lower contrast target; this release does not claim that all dim text meets 4.5:1. This is a rendering fix, not a change to Codex's own theme detection or tmux configuration.

Theme changes do not restart terminal programs, recreate panes, or send commands to the shell. No model API calls are needed.

Upgrade

Update the checkout to this release and reload the browser page. If the frontend is served from a separate deployment directory, update that copy too. The fix only changes frontend behavior; existing tmux jobs can continue running.

Verification

Automated Chromium tests use the real frontend and bundled xterm with anonymous fixture output. They check actual rendered colors, four panes, both themes, system appearance, cross-tab changes, reload, reconnect, and a 390 px mobile viewport. The original low-contrast fixture fails against the previous frontend and passes after this fix.

Developers can run the optional browser tests with Node.js 22+:

npm ci
npx playwright install chromium
npm run test:browser

Node.js and Playwright are test dependencies, not server runtime requirements.

简体中文

解决了什么问题？

用户反馈：网页已经切到深色模式，但 Codex 输入框还是浅灰背景，文字也很浅，几乎看不见。我们用项目实际前端复现了同类问题：RGB (228, 228, 228) 的文字显示在 RGB (238, 238, 238) 的背景上。

原因是终端程序可以自己画背景，有些程序还会记住启动时探测到的配色。网页切换主题后，程序画过的背景不一定跟着更新，而旧版没有对这种低对比度文字做保护。

这次怎么修？

  • 启用 xterm 自带的文字对比度修正，普通文字以 4.5:1 为最低目标。浅底浅字、深底深字都在处理范围内，也覆盖 256 色和真彩色输出。
  • 没有手动指定主题时，系统切换深浅模式，网页和所有分屏一起跟随；手动选过的主题优先。
  • 一个浏览器标签页切换主题后，同一地址下其他标签页同步更新；无效的旧设置自动回退到系统主题。
  • 更新前端脚本版本号，刷新即可加载新版。

程序自己指定的背景色会保留。因此，旧会话中的浅色输入块可能仍是浅色，但普通输入文字会恢复可读。淡化占位文字仍遵循 xterm 较低的对比度目标，不承诺所有淡化文字都达到 4.5:1。这次没有修改 Codex 自身的主题探测或 tmux 配置。

切换主题不会重启终端程序、重建分屏，也不会向 Shell 发送命令；不需要请求模型 API。

怎么升级？

将项目更新到这个版本，再刷新浏览器。如果前端部署在另一份目录，也要同步更新那份文件。本次修复只涉及前端，已有 tmux 任务可以继续运行。

验证了哪些情况？

浏览器测试加载真实前端和项目自带的 xterm，使用匿名模拟输出检查实际渲染颜色。覆盖四分屏、深浅模式、系统主题切换、跨标签页同步、刷新、重连及 390 像素手机视口。同一份低对比度用例在旧版失败、修复后通过。

Assets 2
Loading