protocol: tcp endpoint still runs the HTTP parser on plaintext traffic, and tls: skip cannot be set through policy update --add-endpoint #4903

User Story

I use OpenShell to run sandboxed browser desktops for AI agents. The browser reaches the internet only through a forward proxy that enforces the site list, so a mode change applies instantly instead of waiting for a policy revision. The sandbox policy allows only the proxy endpoint. I directly encountered the HTTP parser rejecting proxy traffic on an endpoint declared as protocol: tcp.

Problem Statement

Two small inconsistencies:

1. An endpoint with protocol: tcp still runs the HTTP parser on plaintext HTTP. A forward-proxy request (CONNECT or absolute-form) is allowed by OPA and then denied by the parser. protocol: tcp reads as "native TCP, no L7" (the validator even says "ask an administrator to add native TCP access explicitly"), so an opaque tunnel was expected.
2. Only tls: skip gives a raw tunnel, and it cannot be set through policy update --add-endpoint. The options segment accepts only allow-uninspected-credentials, websocket-credential-rewrite, request-body-credential-rewrite and allowed-ip=.

Impact / Why This Matters

To allow one proxy endpoint, the operator has to rewrite and re-apply the whole policy file with openshell policy set --policy ... instead of adding a single endpoint. Without reading the parser's denial reason, it looks as if HTTP proxies cannot be used from a sandbox at all.

With a full policy file and tls: skip on the endpoint, the proxy works (HTTP 200 through CONNECT) and the proxy's own allow/deny takes effect. A SOCKS5 proxy on a protocol: tcp endpoint works without tls: skip (not HTTP, so the parser does not engage), which is how we found the difference.

Acceptance Criteria

• Either protocol: tcp skips the HTTP parser, or the docs state that plaintext HTTP on a tcp endpoint is still parsed and only tls: skip gives a raw tunnel.
• tls: skip can be set for a single endpoint through policy update --add-endpoint.

Reproduction Steps

1. Run a plain HTTP forward proxy that supports CONNECT on proxy.internal:3128.
2. Allow it as a native TCP endpoint:

   openshell policy update demo --rule-name egress_proxy \
     --binary /usr/bin/curl --add-endpoint proxy.internal:3128::tcp --wait
   

3. From the sandbox: curl -x http://proxy.internal:3128 https://example.com

The same happens without ::tcp.

Suggested UX (if applicable)

openshell policy update demo --rule-name egress_proxy \
  --binary /usr/bin/curl --add-endpoint proxy.internal:3128::tcp::tls-skip --wait

Environment

• OpenShell: 0.1.5, Kubernetes compute driver
• Runtime: k3s v1.35 on colima, kernel 6.8, containerd 2.3.1

Logs

NET:OPEN [INFO] ALLOWED /usr/bin/curl(0) -> proxy.internal:3128 [policy:egress_proxy engine:opa]
NET:OPEN [MED] DENIED proxy.internal:3128 [policy:egress_proxy engine:http-parser]
  [reason:HTTP request-target rejected: request-target is not a valid origin-form path]