[Bug] hermes debug share uploads logs with credentials to public paste service

[GodsBoy]

Summary

hermes debug share uploads agent log tails and full log files to a public paste service (paste.rs first, dpaste.com fallback). The bug-report, setup-help, and feature-request issue templates explicitly direct users to run hermes debug share and paste the resulting public links into the issue body. The dump portion of the report is already redacted at extract time via hermes_cli/dump.py:_redact (mask_secret). The log portion is not. After PR #16794 made security.redact_secrets off by default, the typical user runs Hermes without local redaction, so logs on disk routinely contain credentials. When that user follows the project's own bug-reporting instructions, those credentials are uploaded to a public paste and linked in a public GitHub issue.

hermes_cli/debug.py currently contains zero references to redact, sanitize, or HERMES_REDACT_SECRETS.

Reproduction

1. With a fresh-default config (no security.redact_secrets: true, HERMES_REDACT_SECRETS unset), use Hermes such that an OAuth token, vendor-prefixed API key, or similar credential reaches ~/.hermes/logs/agent.log (the default tool-output logging path can produce this).
2. Run hermes debug share.
3. Open the printed paste URLs.

Expected: log content uploaded to the public paste does not contain raw credentials.
Observed: log content uploaded as-is, including the credential in plain text on a public paste service.

Why this is a bug, not a feature request

The project's own issue templates direct reporters to walk this exact path. A user filing a bug in good faith (per documented instructions) leaks their credentials on a public service that defaults to a 6-hour TTL but indexes during that window.

Proposed fix

Apply agent.redact.redact_sensitive_text(text, force=True) to log content captured by _capture_log_snapshot in hermes_cli/debug.py before it reaches upload_to_pastebin. The on-disk log files are not modified. A short visible banner is prepended to each uploaded log paste so reviewers reading the paste can confirm the redaction happened. A --no-redact flag preserves the option for deliberate unredacted sharing with maintainer permission.

This is upload-time-only, not local-disk redaction. It does not change security.redact_secrets defaults; it closes the public-leak path that is structurally upstream of the local-redaction question.

force=True is required because the target audience is precisely the population that has not opted into HERMES_REDACT_SECRETS=true; without it, redact_sensitive_text short-circuits at agent/redact.py:322 and the fix is silently a no-op.

Compatibility

• Compatible with feat(security): make secret redaction off by default #16794. Local on-disk logs continue to follow the operator's security.redact_secrets setting. Only the in-memory copy that flows to the public paste service is sanitized.
• The dump portion of the report is unchanged (already redacted via mask_secret).
• Operators who pass --no-redact get current behavior with no banner.
• hermes debug share --local (no upload) honors the same redact-by-default policy.

Scope

• hermes_cli/debug.py: redact log content at the _capture_log_snapshot boundary; prepend a visible banner to each upload-bound log paste; thread a redact parameter through _capture_default_log_snapshots; honor args.no_redact in run_debug_share.
• hermes_cli/main.py: add --no-redact to the debug share argparse + epilog.
• tests/hermes_cli/test_debug.py: pin redaction at the capture boundary, the --no-redact opt-out, and a regression test that ensures force=True keeps working when HERMES_REDACT_SECRETS is unset.

Out of scope: state.db scanning, retroactive on-disk redaction (separate concerns), changes to security.redact_secrets default, new redaction patterns.

I am happy to send a PR

I have a working implementation against current main (66/66 tests pass in tests/hermes_cli/test_debug.py, including 8 new tests). Will open the PR once I see one positive signal here that the approach fits the project's intent.