fix(TaskListV2): revert overflowX hidden that hides task text labels#1215
Conversation
The overflowX="hidden" added in Gitlawb#1211 clips task subject text to nothing when TaskItems are nested inside MessageResponse (the └ prefix constrains available width). The icon survives at 2 chars but the text gets fully clipped, leaving orphaned ✓/■ without any label. Reverts the overflowX="hidden" portion of Gitlawb#1211.
gnanam1990
left a comment
There was a problem hiding this comment.
Thanks for the quick turnaround on this. Confirmed the regression: when TaskListV2 renders nested inside MessageResponse, the " └ " prefix shrinks the available width, and overflowX="hidden" clips the subject text to zero while the 2-char icon survives — so we get orphaned ✓/■ markers with no labels. Reverting just the TaskListV2 portion while keeping the spinner flexWrap="nowrap" fix from #1211 is the right call. Build, smoke, and the suite are clean locally (the two failing tests are pre-existing provider/network ones, unrelated).
One follow-up, not blocking: maxSubjectWidth/maxActivityWidth in TaskItem are still computed from the full terminal columns rather than the reduced width available inside MessageResponse, so the icon-leak case could still appear in very narrow terminals on the nested path. This revert is strictly better than the current clipped-text behavior, so let's land it and track width-aware truncation separately. Could you also split the bun-vs-node runtime note from the description into its own issue so it doesn't get lost here?
Approving.
Apologies — the overflowX="hidden" I added in #1211 was meant to fix the orphaned task icons, but it clips the subject text to nothing when items are nested inside MessageResponse.
Separately, while investigating I noticed a lot of the spinner jitter, occasional mid-screen garbage characters, and other animation glitches disappear when openclaude is run under bun instead of node. The bin shebang currently uses node, and the dev script does too. From what I could see, the difference comes down to how the two runtimes handle stdout write atomicity and microtask scheduling , bun keeps frames coherent end-to-end while node tends to expose intermediate render states. This is probably why CC uses bun.