Safe-output sanitizer rewrites custom-protocol links inside suggestion blocks

[theletterf]

Problem

Safe-output sanitization can rewrite documentation crosslinks that look like custom protocols when they appear inside GitHub pull request suggestion blocks. This corrupts apply-ready patches because the sanitized text becomes the literal replacement that GitHub offers to commit.

We saw this in an Elastic docs review workflow. The review agent produced a suggestion containing an Elastic docs crosslink, and the posted review comment changed the link target to redacted text:

```suggestion
Assign your {{kib}} users a role that grants [access to {{kib}}]((reference/redacted) as well as your `logstash-reader` role.
```

The source target was a docs crosslink, not an external URL. Elastic docs crosslinks can mimic custom protocols or relative URI-like targets, so they do not fit the current HTTPS-domain allowlist model.

Observed example: elastic/docs-content#6934 (comment)
Repo-level mitigation PR: elastic/docs-actions#191

Why this is hard to work around

safe-outputs.allowed-domains can allow expected HTTPS hosts, but it does not help with custom-protocol or hostless crosslink targets. A wildcard domain option, if one exists, also would not necessarily address custom schemes, and using it broadly would weaken the sanitizer for all generated comments.

In this case, the risky part is not rendering a clickable URL in normal comment prose. The risky part is mutating fenced suggestion patch content, which users may commit verbatim.

Potential fixes

• Preserve fenced code regions, especially ```suggestion blocks, when applying URL/protocol sanitization. Suggestion block contents are patch payloads rather than comment links.
• Consider an explicit allowed schemes/custom protocols configuration for safe outputs, if gh-aw wants workflows to opt in to trusted non-HTTPS link schemes.
• Document whether wildcarding all URL domains/schemes is supported or intentionally unsupported, and how workflow authors should handle custom-protocol documentation links.

Expected behavior

Safe-output sanitization should not rewrite link targets inside GitHub suggestion fences in a way that corrupts the patch GitHub offers to apply.

[theletterf]

Follow-up from checking github/gh-aw-firewall implementation: AWF supports wildcard domain patterns, but not an all-domain wildcard.

The validation path rejects broad patterns before generating Squid ACLs:

• * throws Pattern '*' matches all domains and is not allowed.
• *.* throws Pattern '*.*' is too broad and is not allowed.
• Any pattern made only of * and . is rejected.
• Protocol-prefixed broad patterns such as http://* and https://*.* are rejected after stripping the protocol prefix.

Relevant code path:

• src/domain-validation.ts has checkOverBroadPattern() and validateDomainOrPattern().
• src/domain-matchers.ts calls validateDomainOrPattern() from parseDomainList().
• src/squid/domain-acl.ts calls parseDomainList() through parseDomainConfig() before generating Squid ACLs.
• Config network.allowDomains maps to the same allowDomains CLI option.

So wildcarding all domains does not appear to be available through AWF domain permissions. The safer fix for this issue is still to avoid mutating fenced suggestion payloads, or to add explicit support for trusted custom schemes if that is desired.

[pelikhan]

@copilot Safe-output sanitization should not rewrite link targets inside GitHub suggestion fences in a way that corrupts the patch GitHub offers to apply.