xterm WebLinkAddon does not detect links with new line (broken from xterm fit)

[9M6]

I am trying to open codex from openai and authenticate through the link, but for some reason the link is not being detected to be opened:

https://auth.openai.com/oauth/authorize?response_type=code&client
_id=aljsdhfjkahsdkjfhakjsdjkfa&redirect_uri=http%3A%2F%2Flocalh
ost%3A1455%2Fauth%2Fcallback&scope=openid%20profile%20email%20off
line_access&code_challenge=y9F1nT-S38-R5Xa4yu0oXR3kxIq8yd42-bf8P-
Ten78&code_challenge_method=S256&id_token_add_organizations=trues
codex_cli_simplified_flow=true&state=xfkjsadjkghsjkafhgksjhdfgjk
faskjdfhajshdfkjhaskd&originator=codex_cli_rs

Depending on the terminal width it only detects the first line;

Details

• Browser and browser version: Chrome latest
• OS version: MacOS Sonoma
• xterm.js version: latest

Steps to reproduce

1. Open OpenAI -> Codex
2. Login with Account + Click the link

[9M6]

Also tried with Gemini CLI, and made the terminal around 100-200px, and the URL/Links broke and could not detect

[jerch]

Are there whitespaces at the end of each line?

[9M6]

@jerch I am not sure, I didn't see anything (except new lines), but I also can't debug since I'm using the canvas mode; but one thing for sure is that its not the cli/provider problem, I think:

1. Fit adds new lines to the links
2. It fails fetching the entire link due to being parsed by new URL

[jerch]

The url constructor refuses this? ok thats wild, then my only guess is, that there is an illegal char somewhere hidden. You might want to debug that with new URL() separately.

[9M6]

@jerch Its just an assumption from a first look at the code.

For example in the case of Gemini CLI, when the editor is wide enough, the URL is recognized correctly, but then at a certain size WebLinks just recognizes the URL partially.

My assumption is this:

Somehow along the way new lines are inserted into the URL from Fit, now Weblinks trying to parse this links with the new line, and forward it to new URL, then URL just parses the part until the new line.

[jerch]

Well your assumption is wrong. The terminal does not insert newlines on its own, so if there is a newline, then it was there before. Wrapping urls are supported up 2048-ish or so in char length (would have to look up the exact limit).

[9M6]

Hey @jerch thank you for the response; here is a video of the issue I am facing maybe it might provide more insight.

1. When i resize the window, parts of the link become inactive, and some parts work
2. On a certain window size the links are working fine.

CleanShot.2025-10-06.at.19.26.36.mp4

[9M6]

After doing some debugging, seems xterm does not recognize the line to be isWrapped in WebLinksAddon the function _getWindowedLineStrings and processes only the first line.

[9M6]

Related: #3482

[9M6]

Seems the codex issue is persisting on other terminals (warp, ghostty), but I think this edge case should still be handled.

[jerch]

@9M6 Thx for the more detailed report, I kinda did not get from your initial report, that this happens after a resizing. Can you confirm, that the initial rendering without resizing leaves the link intact and working?

Yes there are issues with isWrapped during resizing. What do you mean with the codex issue being persisting on others? They show the same behavior?

[9M6]

Hey @jerch

So, for the codex issue; it seems I can replicate the problem in ghostty, warp and some other terminals; seems its an issue with their Terminal UI builder called ratatui

But for xterm I also managed to replicate the wrapping issue with google gemini cli, when I resized to a certain width the link stopped working;

[jerch]

Did a quickscan on the smaller reflow logic in

xterm.js/src/common/buffer/Buffer.ts

Line 350 in a1d8e96

private _reflowSmaller(newCols: number, newRows: number): void {

isWrapped is eval'ed there, but never adjusted to new wrapping states. Imho thats a bug and the same as #3482. Not sure yet, if increasing reflow is also missing it.