[Bug] Intermittent external egress failure: allowed request is followed by NET:FAIL

Summary

An OpenClaw workload in a long-running OpenShell sandbox can initially call an external API successfully, then later fail without a policy denial. The OCSF audit log records an allowed TCP open and allowed HTTP POST, immediately followed by NET:FAIL.

The failure is intermittent: a later no-credential CONNECT probe to the same host succeeded without changing the sandbox policy or recreating the sandbox.

Environment

• OpenShell CLI/gateway: 0.0.67
• Sandbox phase: Ready
• Network policy revision: 3 (Loaded)
• Client binary: /usr/local/bin/node
• Destination: api.minimax.io:443
• Endpoint type: REST, access: full
• Workload: OpenClaw, triggered from both Dashboard and TUI

Observed OCSF sequence

NET:OPEN  [INFO] ALLOWED /usr/local/bin/node -> api.minimax.io:443 [policy:minimax_api engine:opa]
HTTP:POST [INFO] ALLOWED POST http://api.minimax.io:443/anthropic/v1/messages [policy:minimax_api engine:l7]
NET:FAIL  [LOW] api.minimax.io:443

There is no policy denial in this sequence. The endpoint and exact Node binary were already present in the loaded policy revision. Restarting the OpenClaw gateway did not resolve the failure.

Lifecycle / reproduction characteristics

1. Create a sandbox and configure OpenClaw to use https://api.minimax.io.
2. Allow api.minimax.io:443 for /usr/local/bin/node with REST/full access.
3. The provider works initially.
4. After the sandbox has been in use, OpenClaw requests can begin failing from both Dashboard and TUI.
5. OCSF shows the allowed NET:OPEN and HTTP:POST, then NET:FAIL.

The transition has not yet been reduced to a deterministic time or request count.

Probe after the failure recovered

A later one-shot command in the same sandbox (no policy change or sandbox recreation) showed:

/etc/resolv.conf: nameserver 127.0.0.11; options ndots:0
proxy CONNECT https://api.minimax.io/: HTTP/1.1 200 Connection Established
upstream response: HTTP/1.1 404 Not Found

The 404 is for the unauthenticated root path and confirms only that the proxy could connect to the upstream. It does not prove that the authenticated POST is healthy.

Relation to #2053

This does not appear to match #2053 directly: the sandbox currently reports ndots:0, and the failure is intermittent rather than a stable external-DNS failure. I am filing separately in case the supervisor/proxy needs more diagnostic detail for failures after OPA and L7 authorization.

Expected behavior

Once a loaded network policy has authorized the binary, destination, and HTTP request, the proxy should either complete the request or provide a specific failure reason sufficient to distinguish DNS, upstream TCP/TLS reset, proxy state, and timeout.

Start with the OCSF sequence showing allowed NET:OPEN and HTTP:POST followed by NET:FAIL, then trace the OpenShell supervisor/proxy path for the authorized request. Compare the failing request with the later CONNECT probe and inspect how DNS, upstream TCP/TLS resets, proxy state, and timeouts are reported. Done means the intermittent failure is reproducible or isolated and produces a specific diagnostic reason.