You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This keeps the server listening correctly while allowing pairing information to use the stable hostname clients are actually expected to connect to.
Expected Result
Running:
npx t3 pair
should generate the normal QR code and pairing information using the configured advertised hostname rather than forcing users to use an automatically detected IP address or a separate lower-level pairing command.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Summary
T3 Code should support configuring a persistent custom hostname or base URL for headless servers so that:
returns pairing information and a QR code using that hostname instead of an automatically detected IP address.
Current Behavior
On a headless Linux server, T3 Code can correctly bind to all interfaces with:
T3CODE_HOST=0.0.0.0However, when running:
T3 Code advertises a detected IP address in the pairing information, for example:
In environments with working internal DNS, it would be preferable to advertise something like:
The lower-level command supports specifying a custom base URL:
but this does not provide the same convenient QR-code pairing experience as:
Using:
T3CODE_HOST=server.internal.exampleis also not an appropriate solution because
T3CODE_HOSTcontrols the server's bind address, not just the externally advertised endpoint.Requested Behavior
Please add a persistent configuration option for the hostname or base URL advertised by the headless server during pairing.
For example:
T3CODE_ADVERTISE_URL=http://server.internal.example:3773or:
T3CODE_PUBLIC_URL=http://server.internal.example:3773Then:
would continue to provide its normal pairing URL, token, and QR code, but use the configured hostname.
Alternatively, supporting this directly would also work:
Ideally, both a CLI option and a persistent environment/config setting would be available.
Why This Matters
Headless servers commonly use:
A server's bind address and its advertised or reachable address are separate concerns.
A typical configuration should be able to look like:
This keeps the server listening correctly while allowing pairing information to use the stable hostname clients are actually expected to connect to.
Expected Result
Running:
should generate the normal QR code and pairing information using the configured advertised hostname rather than forcing users to use an automatically detected IP address or a separate lower-level pairing command.
All reactions