What
Forward the client feature flags (TUIST_FEATURE_FLAG_*) into the Xcode compilation cache (CAS) daemon’s launchd-agent environment, so it resolves cache endpoints the same way the rest of the CLI does.
Why
tuist setup cache starts the CAS daemon (cache-start) as a launchd agent, which does not inherit the caller’s environment. Setup only forwarded TUIST_TOKEN, so ClientFeatureFlags was always empty inside the daemon.
Endpoint resolution (CacheURLStore then getCacheEndpoints) relies on the server’s technology selection, which keys off the x-tuist-feature-flags request header (auto-injected from ClientFeatureFlags). With the kura flag the server returns the private-network (kura) endpoint; without it, the default (public) endpoint. Because the daemon never saw the flags, it always resolved the public endpoint, even on runners that can reach a private-network cache.
The binary module cache is unaffected because the server dispatches its endpoint directly, so only the CAS round-tripped every compilation unit to a public endpoint over the WAN, which makes the Xcode cache net-negative on a full compile.
Fix
Forward TUIST_FEATURE_FLAG_* into the agent environment via a new ClientFeatureFlags.environmentVariables() helper. A client flagged for kura now has its CAS daemon request the kura endpoints and resolve the private-network cache.
Validation
- New unit test asserts the feature flags are forwarded into the agent environment.
- Existing tests (token-only and no-token) are unaffected, since the forward only adds flags that are set.
- Built and tested in CI.
Note
This is the client half. For a runner to actually use the private-network CAS, TUIST_FEATURE_FLAG_KURA must be set on the runner job (server/dispatch), which nothing does today. That runner-side change is tracked separately.
Replaces #11480, which forwarded a TUIST_CACHE_ENDPOINT override instead.
🤖 Generated with Claude Code
T