Area
packages/shared / apps/web
Steps to reproduce
- Run
t3 connect in a headless SSH session.
- Take the printed
/connect#state=...&challenge=... URL.
- Insert an invalid character such as a space or
│ into the state or challenge fragment value, simulating corruption while copying a visually wrapped URL from a terminal multiplexer.
- Open the modified URL in a browser.
- Complete the browser authorization flow.
- Paste the resulting code into the waiting CLI.
Expected behavior
The /connect page should reject the malformed request before opening the sign-in or authorization flow.
Because T3-generated values have known formats, the page can validate them before use:
state: 22 base64url characters- PKCE
challenge: 43 base64url characters
The page should explain that the copied connect URL may be incomplete or corrupted and instruct the user to re-copy the freshly printed URL.
Actual behavior
The browser currently accepts any non-empty state and challenge, completes the authorization flow, and displays an authorization code.
The waiting CLI later rejects that code with:
That code belongs to a different connect request. Open the URL above and try again.
The CLI correctly fails closed, so this does not appear to bypass authorization. However, the malformed request is detected only after the full browser flow, and the resulting message does not identify likely URL corruption.
Impact
Minor bug or occasional failure. It can be confusing and difficult to diagnose when a long connect URL wraps in a narrow terminal and terminal UI characters are included during native text selection.
Environment
- T3 Connect headless authorization over SSH
- Narrow terminal viewport
- Terminal multiplexer with visible pane frames
The problem is independently reproducible by manually inserting a non-base64url character, so it is not specific to one terminal application or multiplexer.
Workaround
Disable multiplexer pane frames, widen the terminal, or verify that copied state and challenge values contain only base64url characters before opening the URL.
Area
packages/shared/apps/webSteps to reproduce
t3 connectin a headless SSH session./connect#state=...&challenge=...URL.│into thestateorchallengefragment value, simulating corruption while copying a visually wrapped URL from a terminal multiplexer.Expected behavior
The
/connectpage should reject the malformed request before opening the sign-in or authorization flow.Because T3-generated values have known formats, the page can validate them before use:
state: 22 base64url characterschallenge: 43 base64url charactersThe page should explain that the copied connect URL may be incomplete or corrupted and instruct the user to re-copy the freshly printed URL.
Actual behavior
The browser currently accepts any non-empty
stateandchallenge, completes the authorization flow, and displays an authorization code.The waiting CLI later rejects that code with:
The CLI correctly fails closed, so this does not appear to bypass authorization. However, the malformed request is detected only after the full browser flow, and the resulting message does not identify likely URL corruption.
Impact
Minor bug or occasional failure. It can be confusing and difficult to diagnose when a long connect URL wraps in a narrow terminal and terminal UI characters are included during native text selection.
Environment
The problem is independently reproducible by manually inserting a non-base64url character, so it is not specific to one terminal application or multiplexer.
Workaround
Disable multiplexer pane frames, widen the terminal, or verify that copied
stateandchallengevalues contain only base64url characters before opening the URL.