#23685 Pants logs bearer tokens when reinitializing the scheduler Issue created by gdfast Describe the bug When

remote_store_headers

contains an authentication token and that token changes between invocations, Pants logs both the old and new credentials in plaintext at INFO level:

[INFO] Initialization options changed: remote_store_headers: {'Authorization': 'Bearer OLD_TOKEN'} -> {'Authorization': 'Bearer NEW_TOKEN'}. Reinitializing scheduler...

Our configuration reads the token from an environment variable:

[GLOBAL]
remote_store_headers = { "Authorization" = "Bearer %(env.BUILDBARN_ID_TOKEN)s" }

To reproduce, run a Pants command with this configuration and the daemon enabled, then run another command with a different token while reusing the daemon. Reinitializing the scheduler when configuration changes is expected, but sensitive values should be redacted from the log message. Pants version Which version of Pants are you using?: 2.33.1 (at time of writing, most recent stable) OS macOS. Not tested on Linux. Additional info In

pants/option/options_diff.py

,

summarize_options_map_diff()

formats changed values using their raw representations.

pants_daemon_core.py

includes this diff in the INFO message announcing scheduler reinitialization.

summarize_dynamic_options_diff()

also formats values without redaction, so the fix should cover both paths, including remote store headers, remote execution headers, and the OAuth bearer token option. Redacting entire header dictionaries would also protect credentials supplied through custom headers. Image pantsbuild/pants