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

[derekhsu]

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.

[derekhsu]

Additional probe (same sandbox, no policy change)

I ran five direct, unauthenticated curl POSTs from inside the affected sandbox to the exact path:

POST https://api.minimax.io/anthropic/v1/messages

All five completed with curl_rc=0 and HTTP 401. The missing credential is intentional; 401 confirms the request reached MiniMax rather than failing in DNS, proxy CONNECT, TLS, or L7 authorization. Corresponding OCSF entries were NET:OPEN ALLOWED and HTTP:POST ALLOWED, with no NET:FAIL.

This reinforces that the failure is intermittent/self-recovering. The request that fails in OpenClaw can have the same allow sequence followed by NET:FAIL, while the same policy and path later work repeatedly.

[derekhsu]

Authenticated probe

I also tested from inside the same sandbox using the injected MINIMAX_API_KEY (the value was not printed) with a minimal Anthropic Messages request to https://api.minimax.io/anthropic/v1/messages, model MiniMax-M3, and max_tokens: 1.

Result: curl_rc=0, HTTP 200. This confirms the credential, model, endpoint, proxy path, and upstream API were all healthy at probe time. The report remains an intermittent failure rather than a static policy/configuration error.