bug(supervisor): L7 engine drops request bodies for the sandbox main process #4740

Summary

Since a few days ago, HTTP requests issued by a sandbox's main process lose their request bodies when they pass through the supervisor's L7 engine. The engine logs the request as ALLOWED, the upstream answers 2xx, but the body never reaches the upstream. GETs (no body) work fine; anything with a body (POST/PATCH with JSON or octet-stream) arrives empty at the upstream.

Traffic from openshell sandbox exec processes in the same sandbox does not go through the same path and its bodies arrive intact, which makes the mismatch easy to reproduce.

Environment

• OpenShell v0.1.4 (gateway + CLI), local gateway, docker compute driver, Linux aarch64
• Sandbox created with openshell sandbox create --from <image> --provider <cred-provider> --policy <yaml>
• Reproduces with a minimal main process (no agent code involved)

Minimal reproduction

Main process of a sandbox whose policy allows POST to an endpoint:

// node /sandbox/work/probe.mjs — the sandbox's main process
const response = await fetch("https://discord.com/api/v10/channels/<id>/messages", {
  method: "POST",
  headers: { Authorization: `Bot ${process.env.DISCORD_BOT_TOKEN}`, "Content-Type": "application/json" },
  body: JSON.stringify({ content: "body probe alpha" }),
});
const body = await response.json();
console.log("POSTED", response.status, JSON.stringify(body.content));

The message appears on Discord with content: "" although the worker-side call carried the text and returned 200.

The same POST issued from an openshell sandbox exec process in the same sandbox applies the body correctly (and produces no OCSF HTTP:POST lines, i.e. it does not traverse the same path).

Evidence from the affected workload

1. The process logs the payload it hands to the HTTP client:
   {"event":"transport_edit","chars":108,"head":"“And so my fellow Americans, …"}
2. The supervisor's OCSF log shows the request accepted by the L7 engine:
   OCSF HTTP:PATCH [INFO] ALLOWED PATCH http://discord.com/api/v10/channels/<id>/messages/<id> [policy:<provider> engine:l7]
3. The upstream applies something (edited_timestamp changes) but the stored content is "".

A plain-HTTP (non-TLS) POST through the same engine to a LAN endpoint behaves the same: the engine logs ALLOWED POST, and the upstream never receives usable body bytes.

Expected

A body-carrying request the L7 engine allows must reach the upstream with its body intact (or be denied with a clear error), independent of whether the process is the sandbox's main process or an exec process.

Notes

• The gateway was restarted with no change, and the image, policy file, and provider definition are unchanged between a known-good run (bodies delivered) and the first broken run the next morning, so this does not appear to be caused by a user policy edit.
• The same workload on the same image posted bodies correctly two days earlier, which is why this looks like a state- or ordering-dependent defect in the L7 body forwarding rather than a policy misconfiguration.