fix(gateway): --domain flag not working for non-enroll method

[x032205]

Description 📣

Old enrollment method gateway commands such as:

infisical relay start --name=test --token=... --domain=http://localhost:8080 --host=1.1.1.1

Did not work.

The --domain flag never gets used, and when removed the logged in domain never gets used either. It's ALWAYS app.infisical.com.

This change makes it prioritize domains in the following order:

• --domain flag
• StoredDomain (only if using the new enrollment method)
• Logged in domain

This fix makes domains work for both the old and new enrollment methods.

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

# Here's some code block to paste some code snippets

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[linear]

PAM-242

[infisical-review-police]

💬 Discussion in Slack: #pr-review-cli-252-fix-gateway-domain-flag-not-working-for-non-enroll-method

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[greptile-apps]

Greptile Summary

This PR fixes the --domain flag being silently ignored for gateway/relay start commands that use the old enrollment method (or no enrollment method at all). Domain resolution is consolidated into a single early block applied before any enrollment path, with a clear priority: --domain flag → stored domain → logged-in user domain.

• gateway.go / relay.go: The per-branch domain-resolution blocks are removed and replaced with one unified block that runs unconditionally as soon as the gateway/relay name is known, so --domain, the persisted stored domain, and the logged-in user domain all work regardless of --enroll-method.
• SaveDomain simplification: The old effectiveDomain dance (which re-read the flag and fell back to config.INFISICAL_URL) is replaced with a direct SaveDomain(name, config.INFISICAL_URL) call, since config.INFISICAL_URL is already authoritative by that point.

Confidence Score: 4/5

The fix is correct and well-scoped; the only concern is that no URL validation is applied to the resolved domain before auth credentials are transmitted to it.

The domain resolution refactor is logically sound and the SaveDomain simplification is safe. The open issue is that the new consolidated block never validates the URL scheme or host, meaning credentials are transmitted in plaintext when http:// is used, and a compromised stored-domain config file can redirect tokens to an attacker-controlled server.

Both packages/cmd/gateway.go and packages/cmd/relay.go share the same unvalidated domain-resolution block; URL validation would need to be added in both files (or in util.AppendAPIEndpoint).

Security Review

• Credential exfiltration via unvalidated --domain / stored-domain URL (packages/cmd/gateway.go, packages/cmd/relay.go): The domain value (from --domain flag, LoadStoredDomain, or LoggedInUserDomain) is passed through AppendAPIEndpoint with no scheme, host, or allowlist validation before being assigned to config.INFISICAL_URL. All subsequent API calls — including those carrying enrollment tokens and access tokens — are sent to whatever URL results. A local attacker who can modify the stored-domain config file can redirect token traffic to a server they control.

Important Files Changed

Filename	Overview
packages/cmd/gateway.go	Domain resolution logic unified into a single early block (flag > stored domain > logged-in user domain), fixing the bug where the --domain flag was ignored for non-enrollment-method invocations; no URL validation is applied to the resolved domain before it is used for all outbound API calls.
packages/cmd/relay.go	Same domain-resolution refactor as gateway.go; --domain flag and stored/logged-in fallbacks are now resolved once at the top before any enrollment branch, and SaveDomain now unconditionally persists the resolved URL.

_{Reviews (2): Last reviewed commit: "remove unnecessary enrollmentMethod chec..." | Re-trigger Greptile}

[x032205]

Removed that check because some users may enroll once and then remove the enroll method flag. That way we'd need to check if the flag either exists OR they already have an enrollment token. That check isn't needed, because if the enrollment token exists then the storedDomain also exists 🤣

Therefore just checking if a storedDomain exists is the closest we can get to optimal logic

[x032205]

@greptile re-review this pr