[Feature]: Persistent host binding configuration for the background service

[jelondon]

Problem

Currently, there is no supported, discoverable way to persist a custom bind address for the background service installed by t3 service install. While the t3 serve command supports binding to a custom host via --host flag, this capability is not available for the background service.

The service currently starts through __service-launcher and listens only on 127.0.0.1, with no documented mechanism to configure a different bind address.

Attempts Made

Users have tried several configuration approaches without success:

• Setting T3CODE_HOST environment variable in systemd service configuration
• Setting T3CODE_HOST in shell profile
• Passing host configuration arguments to __service-launcher

None of these resulted in the service binding to a non-loopback address.

Workaround Discovered

A working workaround requires manual configuration outside the standard T3 Code settings:

# ~/.config/environment.d/t3.conf
T3CODE_HOST=192.168.5.40

Then restart the systemd user manager. While functional, this is:

• Difficult to discover
• Requires configuring the user-manager environment instead of T3 Code settings
• Not documented in official guides

Desired Behavior

Provide a supported, documented way to persist custom host binding for the background service. Possible implementations include:

• t3 service install --host 192.168.5.40 command-line option
• A supported configuration file mechanism
• Documented service-specific environment override

Requirements:

• Configuration must survive service restarts and updates
• Loopback (127.0.0.1) should remain the default
• Users must explicitly opt into network access
• Should maintain compatibility with T3 Connect

Use Case

Users want T3 Code to remain available after system reboot or logout while being reachable from other devices on their private network, without manually maintaining a foreground server instance.

Related Issues

• Issue [Bug]: T3 Connect reports "relay offline" when the server binds a non-loopback host #4915 discusses a different problem involving non-loopback binding and T3 Connect
• Documentation gaps: background-service guide and LAN-access guide should document the supported workflow once implemented

Additional Context

• Environment: Ubuntu 26.04.1 LTS
• T3 Code version tested: 0.0.45
• Installation method: t3 service install