fix: keep HF_TOKEN out of vllm argv and mask secret flags in launch log

[danstotts-ops]

Problem

args_builder's generic env scan maps HF_TOKEN to --hf-token <value>, and main.start_vllm logs the full argv at INFO (Starting vLLM: vllm serve ... --hf-token hf_...). The Hugging Face token ends up in plain text in serverless worker logs, and it is visible to anything that can list processes in the container. vLLM's own "non-default args" line already masks it; only the wrapper's line leaks.

Fix

• HF_TOKEN is now in RESERVED_ENV_VARS, so it is never emitted as --hf-token. vLLM's --hf-token defaults to huggingface_hub's own token lookup, which reads HF_TOKEN from the environment the child already inherits (env = {**os.environ, ...}). Gated models keep working with no config change.
• The launch line logs redact_argv(argv), which masks the value of any flag whose last dash-separated word is token, key, secret or password. It handles both --flag value and --flag=value, since VLLM_EXTRA_ARGS can still pass either form. Matching the last word rather than a substring keeps --tokenizer, --max-num-batched-tokens and --ssl-keyfile (a path) readable in the log.
• Docs: HF_TOKEN row in docs/configuration.md, plus a runtime-secrets note in docs/conventions.md.

Tests

tests/test_secret_redaction.py covers the redactor, the look-alike flags, and start_vllm end to end with Popen mocked: the log line contains neither secret, argv has no --hf-token from HF_TOKEN, and the child env still carries HF_TOKEN. Full suite: 122 passed locally.

Follow-up for operators

Any token already printed by an affected image should be treated as exposed and rotated.

🤖 Generated with Claude Code

[kenlim-mops]

Correct security fix. Adding HF_TOKEN to RESERVED_ENV_VARS is the right layer: vLLM's --hf-token already defaults to huggingface_hub's own env lookup, so the child process gets the token through the inherited env without it ever appearing on the command line or in ps output. redact_argv matching on the last dash-separated word of the flag name (not a substring) correctly excludes --tokenizer, --max-num-batched-tokens, and --ssl-keyfile while catching --hf-token, --api-key, and both space-separated and = forms. The test with Popen mocked verifies end-to-end: log line clean, argv has no --hf-token from env, child env carries HF_TOKEN. Note: 'dev' build workflow shows QUEUED (non-blocking); all test/CodeQL checks passed.