You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TLD wildcard patterns in network policy accepted but silently rejected by proxy #787
Network policy entries using TLD wildcards (e.g., *.com, *.org) are accepted by openshell policy set without error, but the proxy silently rejects matching CONNECT requests — 0 bytes returned, connection closed. No denial logged anywhere.
Subdomain wildcards (*.wikipedia.org) and explicit domains (example.com) work correctly.
Environment
OpenShell v0.0.25
Ubuntu 22.04 x64
Sandbox running OpenClaw with HTTP CONNECT proxy at 10.200.0.1:3128
TLD wildcards should match (e.g., *.com matches example.com, en.wikipedia.org)
OR openshell policy set should reject TLD wildcards with a validation error
The current behavior (accepted but silently non-functional) is the worst case for debugging — no error at submission time, no denial log at request time.
Workaround
Use subdomain wildcards (*.wikipedia.org) or explicit domains. For general web access (e.g., web_fetch tool), route through a server-side API like Firecrawl so only api.firecrawl.dev needs to be in the policy.
Notes
The OpenClaw-init deployment guide documents this as "TLD wildcards cause OPA errors," but on v0.0.25 there are no OPA errors — just silent rejection. The behavior may have changed between versions.
Related: #704 (log proxy denials at warn level) — if denials were logged, this would have been immediately obvious.
Activity
johntmyers commentedon Apr 9, 2026
Good find. Thanks. We should reject TLD wildcards, from a security perspective that is way too broad. Will follow up with a PR.
fix(policy): reject TLD wildcard patterns in network policy endpoints
fix(policy): reject TLD wildcard patterns in network policy endpoints (…