fix: redact known Hermes secret env vars regardless of code_file mode

[ShaoRou459]

Problem

Terminal output from non-env-dump commands (cat, type) uses code_file=True which skips the generic KEY=VALUE redaction pass. This causes opaque API keys without recognized vendor prefixes to leak when reading .env files through the terminal.

Leaked keys: Gemini (AQ.*), Mistral (no prefix), Tavily dev keys (tvly-dev-), BrowserUse (bu_), Spotify client IDs (hex).

Root cause

redact_terminal_output sets code_file = not is_env_dump_command(command). For cat, this is True, skipping all _ENV_ASSIGN_RE / _JSON_FIELD_RE / _YAML_ASSIGN_RE passes. Only prefix patterns run — but most of these keys have no recognized prefix.

Fix

1. Manual set of 95 known Hermes secret env var names (LLM providers, tools, messaging platforms, etc.)
2. AST-based auto-scanner that parses tools/*.py for requires_env lists in registry.register() calls — so new tools are automatically covered
3. New redaction pass in redact_sensitive_text that runs before the code_file gate, matching only these known names to avoid false positives on source code like MAX_TOKENS=100

All values are redacted to ***, consistent with the prefix-matcher output.

Verification

• All 149 existing redact tests pass
• Manual verification: cat .env now redacts all 6 previously-leaked keys

[egilewski]

suggesting changes

The new known-env redaction still misses a common .env shape: an inline comment after the value. In agent/redact.py, _HERMES_KNOWN_ENV_RE requires the value to run to end-of-line with (?=\s*$), so terminal/file-read output for a line such as MISTRAL_API_KEY=mistralOpaqueSecret12345 # used for tests still returns the secret value unchanged under the code_file=True path used for cat .env. The same happens for export MISTRAL_API_KEY=... # ....

Security evidence:

• trust boundary: terminal output from file-reading commands is untrusted content before it is returned to the agent/logging surfaces.
• source/sink/invariant: known Hermes secret env var assignments in .env-style output should redact the value under code_file=True, including the optional export prefix and trailing inline comments.
• current-main reproduction: running the redactor from the current-main worktree confirmed MISTRAL_API_KEY=mistralOpaqueSecret12345 and the inline-comment variant both leaked, establishing the pre-existing gap.
• PR-head or patch-replay validation: running the redactor from the PR worktree confirmed the plain assignment now becomes MISTRAL_API_KEY=***, but MISTRAL_API_KEY=mistralOpaqueSecret12345 # used for tests and export MISTRAL_API_KEY=mistralOpaqueSecret12345 # used for tests still leak the value.
• positive/negative cases: the plain known-secret assignment now redacts, MAX_TOKENS=100 remains unchanged under code_file=True, and tests/agent/test_redact.py passes with 149 tests, but there is no coverage for the inline-comment form.
• residual bypass search: the bypass is caused by the new line-end-bound regex in agent/redact.py, before the generic env-assignment redactor is skipped for code/file-read output.
• reviewer validation: the blocker is in-scope because the PR claims to redact known Hermes secret env vars regardless of code_file mode, and the missed examples use the same known key family and file-read path targeted by the patch.

Signed: GPT-5.5-xhigh in Codex

[egilewski]

suggesting changes

The latest head fixes the inline-comment redaction gap from my earlier comment, but it also rewrites tests/agent/test_redact.py with CRLF line endings. git diff --check 73b611ad19720d70308dad6b0fb64648aaadc216 3905781ac31f714acd41119959ae749bd64e1da4 -- agent/redact.py tests/agent/test_redact.py now reports trailing whitespace on the rewritten test file starting at line 1, and git show 3905781ac31f714acd41119959ae749bd64e1da4:tests/agent/test_redact.py | sed -n '1,8l' shows \r on every sampled line. This turns a small redaction/test update into a full-file whitespace rewrite and leaves the patch failing the repository whitespace check, so it should be normalized before merge.

Security evidence:

• trust boundary: terminal/file-read output redaction protects secrets before they reach agent-visible output and logs.
• source/sink/invariant: this follow-up review checked whether the PR's redaction fix remained reviewable and merge-hygienic after addressing the prior inline-comment bypass.
• current-main reproduction: the same file on current main uses normal LF endings in the sampled lines, so the CRLF/trailing-whitespace churn is introduced by this PR head.
• PR-head or patch-replay validation: the current PR head 3905781ac31f714acd41119959ae749bd64e1da4 fails git diff --check with trailing-whitespace reports across tests/agent/test_redact.py.
• positive/negative cases: agent/redact.py is not the whitespace problem, but the test file diff is dominated by line-ending churn (1133 additions and 1048 deletions for the same test file).
• residual bypass search: not continued past this first decisive blocker in till-first-blocker mode; additional redaction issues may remain unchecked.
• reviewer validation: this is in scope because the PR changes security-sensitive redaction tests, and the introduced line-ending/whitespace churn makes the submitted patch fail a standard repository hygiene check before deeper security validation.

Signed: GPT-5.5-xhigh in Codex

[ShaoRou459]

Apologies about the whitespace issue, will watch out going forward.

[teknium1]

Thanks for addressing the code_file=True terminal-output gap; current main confirms the premise at agent/redact.py:741 and agent/redact.py:549.

Problems

• The new scanner is limited to tools/*.py, but provider credentials are declared elsewhere. For example, current main declares NOUS_API_KEY in plugins/model-providers/nous/__init__.py:42; it is absent from the PR's manual list. An opaque NOUS_API_KEY=value therefore still bypasses generic assignment redaction on the cat .env path.
• The added tests call redact_sensitive_text with MISTRAL_API_KEY but do not cover this terminal entry point with a provider credential outside tools/*.py.

Suggested changes

• Include authoritative provider credential declarations in the secret-name source, or add audited coverage for all supported provider env vars.
• Add an end-to-end redact_terminal_output(..., "cat .env") regression using opaque NOUS_API_KEY content.

Automated hermes-sweeper review.

[ShaoRou459]

Following review feedback from @teknium1, replaced the manual list + AST scanner approach with a simpler and more robust solution.

Instead of maintaining a list of ~95 known secret env var names + scanning tools/*.py for requires_env, the fix now detects when a terminal command reads a .env file (cat .env, head .env.local, etc.) and sets code_file=False so the existing _ENV_ASSIGN_RE regex handles redaction. This regex already matches any KEY=value where the key contains API_KEY, TOKEN, SECRET, PASSWORD, CREDENTIAL, or AUTH — covering all current and future env vars with zero list maintenance.

This also resolves the gap @teknium1 identified: NOUS_API_KEY and any other provider credential declared outside tools/*.py is now covered automatically, since we're no longer relying on enumerating declaration sites.

Per AGENTS.md, .env is for secrets only, so running the generic ENV redactor on .env content is the correct behavior to prevent secret leaks. Template files (.env.example, .env.sample, etc.) are explicitly excluded so the agent can still read those freely.

Trade-off for this approach is agent autonomy: Because .env values are now redacted when read through the terminal (the read_file tool already blocks .env entirely), the agent cannot inspect or compare raw secret values in .env files without human intervention. An agent debugging a misconfigured API key would see OPENAI_API_KEY=*** instead of the actual key, and would need to ask the user to verify the value. File writes (write_file, patch) are unaffected — the agent can still create and modify .env files.

• Shaorou459 & GLM5.2 & DSV4Pro

[ShaoRou459]

eh? Conflict of agents

[kshitijk4poor]

Merged via #80964 — your commit was cherry-picked onto current main with your authorship preserved (git log shows you as author on main).

The branch had drifted ~6000 commits; the only conflict was with the test-prune wave, resolved by not resurrecting the pruned tests (two of the carried-over fixtures had also been corrupted by the display-redaction layer into sentinel strings, so dropping them fixed that too). A small follow-up commit on top hardened the detection per review: the basename list is now imported from agent/file_safety instead of copied, the lookup is case-insensitive (cat .ENV), and shell quotes are stripped (cat ".env").

Thanks for the fix — and for iterating through the three design rounds to the routing approach.