TYPO3 site baseVariants fallback order and CLI versus web context drift

Site base resolution when no variant matches

In TYPO3 v9–v13, each site defines a static base URI in config/sites/<identifier>/config.yaml and optional baseVariants that override it when a condition evaluates true. Conditions are evaluated against the application context derived from TYPO3_CONTEXT and the runtime environment. Consequently, a web request and a CLI invocation can resolve different bases.

Missing constraint on fallback precedence

The documentation does not prescribe whether the static base should be the production value with local overrides, or the local value with production overrides. When no variant condition matches, TYPO3 silently falls back to the static base; a local-first setup that sets base to a localhost URL and only overrides production via a variant will serve localhost links whenever the production condition fails. There is no fail-fast guard that errors when the resolved base disagrees with the incoming Host header.

Context boundary between web and CLI

Setting TYPO3_CONTEXT only in the web server vhost leaves CLI entry points such as the scheduler on the default context, so base resolution can differ between frontend rendering and cron tasks. baseVariants also do not touch [SYS][trustedHostsPattern], [SYS][reverseProxyIP], [SYS][reverseProxySSL] or cookie domains, so a correct base can still be rejected or loop behind a proxy.

What is the recommended fallback strategy for the static site-base value to avoid silent localhost leakage in production? How can a project enforce that the resolved base matches the public host without custom middleware? Does TYPO3 provide any built-in diagnostic to surface context drift between web and CLI base resolution?