weekly-research workflow uses WebSearch despite only declaring web-fetch in tools AND redacts all URLs in its research

[benissimo]

Summary

The weekly-research.md workflow only declares web-fetch: in its tools block, but at runtime on the Claude engine, WebSearch is implicitly available as a default tool. The model then calls WebSearch repeatedly — which works, but produces a report full of redacted URLs, undermining the value of a research workflow.

Per the gh-aw tools reference, web-search: requires explicit declaration for Codex but appears to be default-on for Claude. This means the workflow silently depends on engine-specific defaults rather than explicitly declaring its intent.

Observed behavior

1. Workflow tools block declares only web-fetch: (no web-search:)
2. gh-aw correctly passes --allowed-tools ...WebFetch... (no WebSearch) to the Claude CLI
3. Claude engine makes WebSearch available anyway (default-on behavior)
4. Model calls WebSearch multiple times for research queries
5. Results contain redacted URLs — "safe" but defeats the purpose of a web research report

Suggestions

1. Add web-search: to the workflow's tools block — makes the intent explicit, ensures cross-engine compatibility (particularly Codex where it's off by default), and signals that the search results are expected to be useful (not redacted)
2. Address the redacted URL problem — a research workflow that searches the web but returns redacted URLs produces output that's hard to act on. If web-search: is the intended tool, the results should include actionable links

Why this matters

• Sample workflows set the pattern for the community — implicit engine-specific defaults are confusing for anyone building their own workflows
• The workflow would silently break or degrade on Codex without web-search: declared
• Redacted URLs in a research report undermine the workflow's stated purpose

[benissimo]

Quick update on the redaction half of this — root cause isn't WebSearch vs web-fetch per se. Redaction happens in actions/setup/js/sanitize_content_core.cjs as a post-process on the safe-outputs body and is tool-agnostic: it rewrites any URL whose domain isn't on the merged network.allowed + safe-outputs.allowed-domains allowlist to (domain)/redacted, regardless of which tool produced the URL.

There's no permissive mode in the sanitizer today — "*" works for the egress firewall but is explicitly rejected by the safe-outputs validator, and no reputation hook exists. Adding web-search: (good for cross-engine portability) doesn't change the redaction outcome; it just changes which URLs the model surfaces.

Filed github/gh-aw#33970 upstream asking for either a safe-outputs.url-policy: audit|reputation mode or accepting "*" in the allowlist validator. Open-web research workflows are the canonical case where static allowlisting doesn't scale.

Interim mitigation in our fork (allowlisting the research domain categories the weekly-research workflow actually cites): RealPage/ai-internal-enablement#563. Holding pattern until the upstream policy mode lands.