fix(redact): stop DB-connstr redaction from corrupting code output (#33801)

[teknium1]

Summary

Reading or echoing a source file that contains a postgresql:// (or mysql/redis/mongodb/amqp) f-string template no longer shows corrupted, line-dropped output. Fixes #33801.

Root cause: _DB_CONNSTR_RE's password group [^@]+ was greedy across newlines. On a multi-line block it matched from the DSN line past the next stray @ it could find — typically a Python @decorator on a later line — and replaced everything in between (including the line breaks) with ***. That dropped lines and concatenated the next line onto the DSN line, so read_file / terminal / execute_code output looked corrupted. The file on disk was always correct (md5sum confirms it), which is why the reporter saw a phantom write-failure loop.

The reporter's stated premise — that redaction mutates tool payloads before write/execute — does not hold on current main: write_file writes content verbatim, and terminal/execute_code only redact their output, never the command or source. The real defect is entirely in the display/output path.

Changes

• agent/redact.py:
  • Forbid whitespace in the DSN userinfo and password groups ([^:\s]+ / [^@\s]+). A real connection-string password never contains whitespace, so the match can no longer span a line break — this alone kills the catastrophic line-dropping.
  • Under code_file=True, preserve a password group that is a pure {...} brace expression — f"postgresql://{user}:{pass}@{host}" is an f-string template, not a live credential. Literal passwords are still masked.
• tools/terminal_tool.py, tools/code_execution_tool.py: pass code_file=True at the output-redaction call sites (file_tools already did), so code-execution output isn't corrupted by ENV/JSON/template false positives. Real prefixes, auth headers, JWTs, and private keys are still redacted.
• Tests: regression coverage for the multi-line repro, brace-template preservation, and continued masking of literal credentials across all DSN schemes; updated one existing terminal-output assertion to the new (correct) mask behavior.

Validation

Case	Before	After
Multi-line block with postgresql:// f-string + decorator (read_file output)	DSN line ***-corrupted, blank line + decorator dropped/concatenated	All lines intact, verbatim
f"postgresql://{user}:{pass}@{host}" (code output)	{pass} → ***	preserved
Literal postgresql://admin:realpw@host (output)	masked	still masked (***)
Real sk-/JWT/auth-header in output	masked	still masked
On-disk file content	verbatim	verbatim (unchanged)

• scripts/run_tests.sh tests/agent/test_redact.py tests/tools/test_terminal_output_transform_hook.py tests/tools/test_code_execution.py → 178 passed.
• E2E against the reporter's exact pydantic-settings module via the real write_file → read_file chain (temp HERMES_HOME): file written verbatim, displayed output shows the DSN f-string + @model_validator intact with zero *** corruption; a literal DSN password and a real sk- key are still masked in displayed output.

Reported-by: koishi70, pfrenssen

Infographic

[tonydwb]

Code Review Summary

Verdict: Approved

Fixes two distinct issues in _DB_CONNSTR_RE: (1) greedy [^@]+ matching across newlines, swallowing intervening lines when a DSN coexists with a Python @decorator; (2) f-string template passwords (e.g. f"postgresql://{user}:***@{host}") being redacted under code_file=True. The new regex properly bounds the password group with [^@\s]+ and the code_file path preserves pure {...} brace expressions. Comprehensive test coverage for multiline corruption, f-string preservation, and all supported schemes. The code_file=True flag is also correctly threaded through terminal_tool.py and code_execution_tool.py.

---

Reviewed by Hermes Agent

[alt-glitch]

This was generated by AI during triage.

Same redaction-corruption cluster for #33801 as the open competing PRs #33840, #39001, #52172 (and sibling #47348 for #47169) — related, not a duplicate. This PR's mechanism is narrowing the DSN userinfo/password regex to forbid cross-newline matches plus code_file=True at the terminal/code-exec output sites. Flagging the cluster so a maintainer picks the canonical fix; not closing any.