Text gets muffled sometimes, in both TUI default and fullscreen

[rounakdatta]

This muffling of text is my biggest problem in using this software on phone. I'm unable to fully reproducce why this is happening, and how we can have a reliable fix for it.

[Ark0N]

Hey thanks for the report, can you give me more information about which setup you are using? Which browser and version, which android, how do you connect?

[rounakdatta]

I'm using Android 16 (OriginOS 6) and this is Chrome browser. My setup is a bit complex - https://github.com/rounakdatta/agentfest - this is my packaging over vanilla codeman. I have a full fledged deployment of this on a VPS and a neat browser URL (not plain Tailscale based) via which I connect.

[rounakdatta]

Found it. Fix is in #431.

It is not a rendering glitch — it is the browser terminal and the PTY disagreeing about how wide the screen is.

Claude Code's TUI wraps its frame at the width the PTY reported, and erases the previous frame by moving the cursor up the number of rows it believes that frame occupied. When the browser terminal is a different width, each line takes more physical rows than the CLI counted, so its erase clears too few of them and the new frame paints over rows that were never cleared. That is exactly the two things in the screenshot: lines appearing twice, and a short tool summary sitting inside a longer sentence with the tail of the sentence still showing.

Reproduced against the same xterm this app ships — a PTY that thinks it has 120 columns, rendered into a 62-column terminal, draws every wrapped line twice.

Why it was so hard to pin down

Because nothing could see it. Resize was write-only: the browser told the server a size and never learned whether it took. Four separate things could make the two disagree, all silently:

• fitAddon.fit() sized the terminal to the raw measurement, while the server was told that measurement floored at 40x10. Any time the floor applied, they diverged. Raising the font on a phone is enough — at font size 44 on a 430px screen, the measurement is 13 columns, the server was told 40, and the terminal stayed at 13.
• Two paths deliberately withheld the resize from the server (while the keyboard is up, and for a session popped out into its own window) but still reflowed locally — which is the one combination that cannot be right.
• Changing the font size, family or weight moves the cell size, so it changes the column count. None of them told the server anything.
• If you have this session open on a desktop at the same time, the server silently ignores the phone's resize for up to 90 seconds after any desktop activity, and never said so.

It self-heals on the next full repaint, which is why it comes and goes — but the garbled rows are already committed to scrollback by then, so what you screenshot is the wreckage of a window that has already closed. That is also why it resists reproduction.

What changed

One function now owns the terminal's size: it measures, applies the floor, and reports the same numbers, so the two cannot drift. Withholding the resize now withholds the reflow too. Font changes tell the server. And the server answers every resize with the geometry the PTY actually has, so a client whose request was declined adopts it instead of rendering against a screen that does not exist — if that leaves the pane wider than your phone, it scrolls sideways rather than being silently cut off.

Worth knowing

Given your setup, the most likely trigger is the third or fourth one. Two questions that would confirm which:

1. Do you ever have the same session open on a laptop while you are on the phone?
2. Does it tend to follow a font-size change, or the keyboard opening?

Either way the fix covers all four, so you should not need to answer before trying it. Verified in Chrome at phone widths against a live server, including the two-device case — but not yet on real Android hardware, which is where you would be the one to tell us.

🤖 Generated with Claude Code

[Ark0N]

The fix for this shipped in 1.32.1, from @rounakdatta's #431 and #470: the browser terminal and the PTY can no longer disagree about their width, which is what made Claude's repaint erase the wrong number of rows. I've only verified it in headless browsers, so I'm leaving this open for a bit. If anyone who saw the muffled text can run 1.32.1 on a real phone for a day and report back, I'll close it.

[Ark0N]

Closing this, since the width fix from your #431 and #470 has been out since 1.32.1 and nobody has reported muffled text since. If it shows up again on 1.32.1 or later, please reopen and add a screenshot, and if you can, the output of tmux -L codeman display -p -t <session> '#{pane_width}x#{pane_height}' next to the terminal size shown in the browser. That comparison tells us straight away whether it's the same bug or a new one. Thanks again @rounakdatta for tracking the cause down yourself.