hermes - 💡(How to fix) Fix Security scanner false-positive: sed delimiter `|` flagged as invalid hostname character

Summary

Hermes' built-in security scanner flags a sed invocation in the bundled github-pr-workflow skill (and likely others using the same idiom) as containing an invalid DNS hostname, when in fact the | characters in the pattern are sed's alt-delimiter syntax — not part of any URL or hostname.

Repro

The skill at skills/github/github-pr-workflow/SKILL.md (also referenced from skills/github/github-auth/SKILL.md and scripts/gh-env.sh) contains this fallback for extracting a token from ~/.git-credentials:

GITHUB_TOKEN=$(grep "github.com" ~/.git-credentials | head -1 \
  | sed 's|https://[^:]*:\([^@]*\)@.*|\1|')

When the agent invokes this snippet through its terminal/code-execution tool, the security scanner emits:

[HIGH] Invalid characters in hostname: Hostname '.*|\1|' contains
characters that are never valid in DNS names

The scanner appears to be tokenizing on https:// and treating everything between it and the next whitespace as a candidate hostname. That misses two facts:

1. The literal between https:// and the closing ' is a sed substitution pattern, not a URL. The leading s|...|...| form uses | as the regex delimiter (since / would need escaping inside a URL-like pattern).
2. | is never a valid hostname character (RFC 1123), which the scanner correctly knows — it's the trigger here. But the input it sees was never claiming to be a hostname; it was a sed pattern.

Impact

• All 5 bundled github-* skills (github-auth, github-code-review, github-issues, github-pr-workflow, github-repo-management) include this idiom or call into gh-env.sh which contains the same line.
• Skills hit the scanner when running the fallback path (no gh CLI installed in the upstream image, and $GITHUB_TOKEN empty in the sandbox env which is normal — code_execution_tool.py scrubs *_TOKEN).
• User-visible failure mode: skill aborts with the HIGH-severity scanner block, prompting the user for input it can't actually use.

Suggested fix

Either:

1. Scope the URL/hostname scanner to actual URLs — match https?:// only when the next characters are URL-safe (i.e., not a regex metacharacter) and end at a real URL terminator. A '-quoted string starting with https:// followed by [^:]*:\(... is clearly not a literal URL.
2. Allow-list sed/awk/perl script bodies when the surrounding shell context shows the string is a substitution/match pattern.

(1) is simpler and probably enough.

Environment

• nousresearch/hermes-agent:v2026.4.30
• Reproduced 2026-05-09 from a self-hosted homelab K8s deployment.

Workarounds (not asking for these to be merged here — just noting)

• Rewrite the regex without | delimiters: sed 's/https:\/\/[^:]*:\([^@]*\)@.*/\1/' — escapes the URL slashes, but is harder to read.
• Use awk -F'[:@]' or python one-liner to parse the credentials file instead of sed.

Happy to send a PR if useful — let me know which fix direction you'd prefer.