Windows desktop: shaded segment of /status rate-limit bar renders above the filled segment

Old:
<img width="709" height="143" alt="Image" src="https://github.com/user-attachments/assets/53b20892-9729-4d8c-a01a-11adf7941433" />

New:
<img width="702" height="132" alt="Image" src="https://github.com/user-attachments/assets/75809e28-11a2-4e6c-8873-db62730f159f" />

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.3351.0 (Codex Beta, Windows MSIX)

What subscription do you have?

ChatGPT plan type prolite (as reported by account/read)

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

In the Codex Desktop /status dialog, the shaded part of a rate-limit progress bar renders almost twice as tall as the filled part and protrudes upward by approximately one text row.

For example, with 96% remaining, the left/remaining segment is rendered normally, while the two shaded cells representing the consumed 4% extend above it. The displayed percentage and horizontal widths are correct; only the glyph geometry is wrong.

Observed pixel geometry in the captured dialog:

• filled segment: x=100..403, y=106..119 (304x14 px)
• shaded segment: x=404..416, y=93..119 (13x27 px)
• both segments share the same bottom edge, but the shaded segment protrudes 13 px upward

What steps can reproduce the bug?

1. Run Codex Desktop on Windows with the default code font stack (which resolves to Consolas).
2. Open a local task.
3. Enter /status.
4. Look at a rate-limit row where the remaining percentage is not 100%, for example:

7d limit: [██████████████████████████████████████████████░░] 96% left

1. Observe that the ░ cells extend above the █ cells.

The session ID is intentionally redacted because it is not needed to reproduce this rendering issue.

What is the expected behavior?

The filled and shaded portions of the progress bar should have identical height and vertical alignment. The shaded segment must not overlap the row above.

Additional information

Root cause

The installed desktop bundle builds this progress indicator as a single Unicode string in app.asar/webview/assets/composer-fNVaowB-.js:

return `${"█".repeat(filledCells)}${"░".repeat(emptyCells)}`;

The surrounding styles use font-mono text-xs leading-relaxed and font-semibold. On Windows, the default mono stack resolves to Consolas.

A standalone font-metrics reproduction with Consolas 11 px Bold matches the screenshot:

• U+2588 FULL BLOCK: approximately 13 px high
• U+2591 LIGHT SHADE: approximately 25 px high and starts 13 px higher

With Cascadia Mono, both glyphs have the same height. Changing Settings → Appearance → Code font to Cascadia Mono is therefore a working workaround.

The span also uses overflow-hidden, but it is an inline span, so the protruding glyph ink is not clipped to a fixed block height.

Suggested fix

Prefer a font-independent CSS progress bar, or render both portions with geometry that does not depend on different Unicode glyph ink boxes. If text glyphs are retained, use a fixed-height inline-block/clip container and add a Windows regression test using the default font stack.

Related PRs are not fixes for this desktop issue:

• #6625 changes contrast in the Rust TUI and replaces shaded cells there
• #6621 changes used-versus-remaining semantics in the Rust TUI

The Electron/Desktop frontend involved here is separate from the public Rust TUI implementation.