You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Flutter 3.38 run command line arguments not working for web development config #179014
From 3.38 it is not possible to pass in the command line the following parameters:
web-hostname
web-port
web-tls-cert-path
web-tls-cert-key-path
This issue has been introduced by this PR: #172175
The implementation document states:
Configuration Precedence
A small but critical section to prevent user confusion, explicitly stating the override order:
Command-Line Arguments (e.g., --web-port)
web_dev_config.yaml settings
Built-in default values
And (some) of the command line arguments are still available in flutter run -h
--web-tls-cert-path The certificate that host will use to serve using TLS connection. If not provided, the tool will use default http scheme.
--web-tls-cert-key-path The certificate key that host will use to authenticate cert. If not provided, the tool will use default http scheme.
But regardless of the above, the implementation now ignores command line arguments and fully relies on the newly introduced web_dev_config.yaml.
From Flutter 3.38, the behavior of web dev server configuration no longer matches the documented precedence. The design doc and https://docs.flutter.dev/platform-integration/web/web-dev-config-file both say: (1) CLI flags (--web-hostname, --web-port, --web-tls-cert-path, --web-tls-cert-key-path), (2) web_dev_config.yaml, (3) built‑in defaults. In practice, the tool now always loads web_dev_config.yaml and uses those values even when the same options are passed on the command line. This effectively makes the CLI flags non‑functional whenever web_dev_config.yaml is present. For example, flutter run -d chrome --web-port=1234 --web-hostname=localhost still binds to the host/port from web_dev_config.yaml. The implementation in WebDevServerConfig.loadFromFile + copyWith should treat the YAML file as the base and overlay any non‑null CLI arguments on top. That is, fileConfig = loadFromFile(...) should be followed by something like fileConfig.copyWith(host: stringArg('web-hostname'), port: webPort, https: httpsConfig, headers: extractWebHeaders()). This would restore the documented precedence: CLI > config file > defaults. Right now there is a mismatch between docs/design and actual behavior, and it’s a breaking change for setups that depended on runtime CLI overrides (e.g. CI, scripts).
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
darshankawar commentedon Nov 25, 2025
Thanks for the report. Keeping the issue open for team's tracking.
fayzan101 commentedon Dec 9, 2025
From Flutter 3.38, the behavior of web dev server configuration no longer matches the documented precedence. The design doc and https://docs.flutter.dev/platform-integration/web/web-dev-config-file both say: (1) CLI flags (--web-hostname, --web-port, --web-tls-cert-path, --web-tls-cert-key-path), (2) web_dev_config.yaml, (3) built‑in defaults. In practice, the tool now always loads web_dev_config.yaml and uses those values even when the same options are passed on the command line. This effectively makes the CLI flags non‑functional whenever web_dev_config.yaml is present. For example, flutter run -d chrome --web-port=1234 --web-hostname=localhost still binds to the host/port from web_dev_config.yaml. The implementation in WebDevServerConfig.loadFromFile + copyWith should treat the YAML file as the base and overlay any non‑null CLI arguments on top. That is, fileConfig = loadFromFile(...) should be followed by something like fileConfig.copyWith(host: stringArg('web-hostname'), port: webPort, https: httpsConfig, headers: extractWebHeaders()). This would restore the documented precedence: CLI > config file > defaults. Right now there is a mismatch between docs/design and actual behavior, and it’s a breaking change for setups that depended on runtime CLI overrides (e.g. CI, scripts).
kevmoo commentedon Dec 12, 2025
The in-flight PR from @Saqib198 looks like it has a fix! I'll baby site to make sure it lands
Restore CLI precedence for web headers and HTTPS over web_dev_config.…
github-actions commentedon Jan 21, 2026
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.