Identify which device is asking and which is approving
Jellyfin’s Quick Connect workflow uses a new client displaying a temporary six-character code and another client already signed in to approve it. Its support table separates those two capabilities. For example, Android TV and Roku are listed for login but not authorising others, while the web client supports both. A television showing a code does not establish that it should also contain the approval interface for another device.
Use the already authenticated client deliberately
The documented approval route is Settings and Quick Connect on a supporting signed-in client, where the displayed code is entered. The server can disable Quick Connect entirely. An invalid or expired code requires another attempt. These conditions should be checked before treating the absence of an authorisation control as a lost user account or an unavailable media library.
Match the two screens before approving
For example, a household setting up its own television can leave that television’s code visible and use its already signed-in browser to authorise the intended client. Verify the server and the newly displayed code rather than approving a code supplied by an unrelated caller. Keep the code out of public screenshots. If the expected action is missing, record which client was used in each role and whether the server has the feature enabled. This describes a login workflow; it does not grant access to media that the selected local user is not permitted to view.
Questions, answered
Should every client that displays a code also approve other devices?
No. Jellyfin documents those as separate client capabilities.