Description

The OpenClaw version pinned by NemoClaw (min_openclaw_version: "2026.4.24", image digest sha256:b3d832b596ab6b7184a9dcb4ae93337ca32851a4f93b00765cc12de26baa3a9a in nemoclaw-blueprint/blueprint.yaml as of v0.0.37 and main) contains openclaw#48554 — proxy-fetch.js coerces FormData request bodies to the literal string [object FormData] when HTTPS_PROXY is set, breaking every multipart upload made from inside the sandbox.

The OpenClaw fix shipped on 2026-05-02 in commit b9c23547 and is published on npm as openclaw@2026.5.7 (current latest).

Concrete impact on my stack: Telegram voice notes routed through OpenClaw to a local STT service (POST /v1/audio/transcriptions) arrive at the upstream as a plaintext body of literally [object FormData] with Content-Type: text/plain;charset=UTF-8 instead of multipart, so the upstream returns HTTP 422. This affects any OpenClaw audio/file/image upload that traverses the OpenShell sandbox proxy.

Why this can't be worked around inside stock NemoClaw

I tried the NO_PROXY bypass approach from #3190 / PR #3013 first. It does not help in my topology:

• host.openshell.internal is statically mapped to 172.17.0.1 via Kubernetes HostAliases inside the sandbox pod (/etc/hosts).
• The OpenShell proxy at 10.200.0.1 can reach 172.17.0.1:<port> because it runs on the host; the sandbox pod (flannel network 10.42.0.0/16) cannot — every directly-routed connection attempt to host-published docker-compose ports refused (connection refused for ports 4000, 8000, 11435, 11436, 11437 on 10.42.0.1).
• So when NO_PROXY is broadened to include host.openshell.internal, OpenClaw's proxy-fetch.js short-circuits to native fetch() correctly, but the request then has nowhere to go because the pod has no direct route to the docker-compose host gateway.

In other words, in a k3s sandbox + docker-compose host services topology, the proxy is the only network path, and the proxy path requires the OpenClaw FormData fix.

There is also no in-sandbox upgrade path: the base sandbox policy marks /usr read-only, so openclaw update (which does npm install -g openclaw@latest) cannot persist the new version in /usr/local/lib/node_modules/openclaw.

The only mechanical lever I have access to as a user of stock NemoClaw is the version pinned in nemoclaw-blueprint/blueprint.yaml — hence this request.

Proposed Change

In nemoclaw-blueprint/blueprint.yaml, bump:

• min_openclaw_version from "2026.4.24" to "2026.5.7" (or current latest)
• digest and components.sandbox.image to a registry image whose openclaw --version reports ≥ 2026.5.7

agents/openclaw/manifest.yaml should also be updated:

• expected_version: "2026.4.24" → "2026.5.7"

After the bump, existing sandboxes apply the fix via nemoclaw <name> rebuild.

Checklist

• I confirmed this bug is reproducible
• I searched existing issues — closest are #3190 (NO_PROXY default — separate fix, doesn't help in this topology) and openclaw#48554 (the upstream OpenClaw bug that has the fix). I did not find an existing NemoClaw issue tracking the OpenClaw version bump.

Reproduction Steps

1. Onboard a sandbox on stock NemoClaw v0.0.37 (or any tag in v0.0.31..v0.0.37 — they all pin the same OpenClaw digest).
2. Stand up an OpenAI-compatible STT service on the docker host, published on host.openshell.internal:11436 (in my case AI4Bharat IndicConformer behind FastAPI).
3. Configure OpenClaw via ~/.openclaw/openclaw.json:

   {
     "tools": {
       "media": {
         "audio": {
           "enabled": true,
           "models": [{
             "provider": "openai",
             "model": "stt-indic",
             "baseUrl": "http://host.openshell.internal:11436/v1",
             "apiKey": "${LITELLM_MASTER_KEY}"
           }]
         }
       }
     },
     "models": {
       "providers": {
         "openai": { "request": { "allowPrivateNetwork": true } }
       }
     }
   }

4. Send any voice note through the configured Telegram channel.
5. STT receives an HTTP 422 with the request body being the literal text [object FormData].

Environment

• Host: DGX Spark, Ubuntu 24.04, aarch64
• NemoClaw: v0.0.31 installed; behaviour also reproduces on v0.0.37 source per min_openclaw_version/digest pins on main
• OpenShell sandbox topology: k3s pod (flannel 10.42.0.0/16)
• Local services: docker-compose stack on the docker bridge (172.17.0.0/16), exposed via host.openshell.internal:11436 (STT) and :11437 (TTS)
• Bundled OpenClaw: 2026.4.24
• Latest published OpenClaw on npm: 2026.5.7 (dist-tags.latest)

Debug Output

Logs

### Server-side log (STT)


WARNING:stt-indic:422 path=/v1/audio/transcriptions ct='text/plain;charset=UTF-8' \
  len=16 head=b'[object FormData]' \
  errors=[{'type': 'missing', 'loc': ('body', 'file'), 'msg': 'Field required', ...}]


`Content-Type` is `text/plain` (not `multipart/form-data; boundary=…`) and the body is 16 bytes of the literal stringified `FormData` — precisely the symptom that openclaw#48554 / commit `b9c23547` fixes.

Verifying the same request flow with `openclaw@2026.5.7` (built locally from npm and tested outside the sandbox to isolate the OpenClaw fix from NemoClaw's pinning) produces a correct multipart body and a successful transcription.

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate