[Feature]: Allow native services to load an environment file

[vladbisceanu]

Before submitting

• I searched existing issues and discussions.
• This describes a concrete background-service use case.

Area

apps/server

Problem or use case

t3 service install creates a native systemd or launchd service, but there is no way to give that service an operator-owned environment file.

A background service does not normally inherit variables from an interactive shell. This matters when provider sessions and their child commands need service-wide settings such as proxy configuration, certificate paths, tool configuration, or credentials for tools that only support environment-based authentication.

Repository .env files are a different concern and should remain owned by each repository. T3's per-provider environment settings are also different because they apply only to a selected provider instance.

Today an operator must choose between:

• wrapping t3 serve in a custom launcher;
• adding platform-specific service-manager configuration;
• putting literal values into a launchd plist;
• duplicating shared values across provider instances.

The wrapper option means no longer using T3's native service lifecycle directly. Platform-specific configuration also behaves differently between systemd and launchd.

Proposed solution

Allow the native T3 service to load one explicitly configured environment file before starting the server.

For example:

t3 service install --env-file /absolute/path/to/t3-service.env

The command shape is only illustrative. The useful behavior is:

• T3 stores the file path, not its contents;
• the service reads the file once during startup;
• values enter the server process environment and are inherited by child processes normally;
• service reinstall and update operations preserve the configured path;
• T3 does not log or copy the values into its settings or service definition;
• a missing or unreadable configured file produces a clear startup error;
• changing the file takes effect after a service restart.

T3 should not search repositories for .env files or load them automatically.

Why this matters

systemd supports EnvironmentFile=, but launchd has no equivalent. Since T3 already owns native service installation on both platforms, it can provide one consistent configuration mechanism instead of requiring every operator to maintain a wrapper.

This would also help installations that use a local secret manager to materialize a protected environment file, without making T3 depend on any particular secret manager.

Smallest useful scope

One trusted, explicitly configured environment file loaded when the native background service starts.

No UI, hot reload, per-project environment, per-provider reconciliation, secret-manager integration, or shell-profile import is required.

Alternatives considered

• A systemd drop-in works on Linux but does not solve the launchd case.
• launchd EnvironmentVariables embeds literal values in the plist and has no file-loading option.
• A wrapper around t3 serve works but replaces the native service entry point.
• Per-provider environment settings do not cover shared child-process configuration.

Risks or tradeoffs

Every child process can inherit these values. The feature should therefore require an explicit, trusted absolute path and should never automatically load a repository-controlled file. Environment precedence should be deterministic and documented.

The operator remains responsible for the file's ownership and permissions.

Related

#5840 describes the same macOS launch-context limitation for the desktop app. This proposal is limited to services installed through t3 service install.

Contribution

• I can implement this immediately.
• I can test it against native macOS launchd and Linux systemd services.