openclaw - 💡(How to fix) Fix Agent runtime JSON.parses gzipped HTTP responses (Unexpected token '\u001f')

Summary

Agent runtime in OpenClaw 2026.5.12 (f066dd2) repeatedly fails with:

SyntaxError: Unexpected token '\u001f', "\u001f\b\u0000\u0000\u0000\u0000\u0000\u0000\u0003"... is not valid JSON

The leading bytes 1f 8b 08 00 00 00 00 00 00 03 are the standard gzip magic + header (method=deflate, OS=Unix). Something in the agent runtime is calling JSON.parse on a gzipped HTTP response body without honoring Content-Encoding.

Where it surfaces

The error appears across multiple lanes — including ones that have no user code involved — so this is internal to OpenClaw, not a user transform/hook bug.

warn  gateway/hooks   sourcePath=/hooks/github-pr-review status=error
                      summary="Unexpected token '\u001f', \"\u001f\b\u0000...\" is not valid JSON"
error diagnostic      lane=cron-nested
error diagnostic      lane=session:agent:main:signal:direct:+...
error diagnostic      lane=main
error                 Embedded agent failed before reply: Unexpected token '\u001f' ...

The lane=main errors are the smoking gun — those runs are not tied to any user-defined hook.

Confirmed: not user code

The PR-review hook's transform (~/.openclaw/hooks/transforms/github-pr-review.ts) is a pure synchronous function that reads pre-parsed ctx.payload and returns a string. It never calls JSON.parse, never makes HTTP calls. Removing it would not stop the lane=main errors.

Reproduction

1. Run 2026.5.12 with GitHub Copilot provider configured (provider: github-copilot, model: claude-opus-4.7).
2. Trigger an embedded agent run (e.g., a chat turn or any cron-nested lane that calls the model).
3. Observe Embedded agent failed before reply with the gzip-magic JSON parse error.

Workaround that confirms the diagnosis: setting NODE_OPTIONS='--require ./no-gzip.js' where the shim wraps globalThis.fetch and undici.fetch to force Accept-Encoding: identity on every outbound request. With the shim active, the error stops, which proves a server in the chain is returning gzip and OpenClaw is parsing it without decompressing.

Likely culprits

A bundled HTTP client somewhere in OpenClaw is doing one of:

// Pattern A: manual buffer → JSON
const buf = await res.arrayBuffer();
JSON.parse(Buffer.from(buf).toString("utf8"));

// Pattern B: piping raw stream to a string then parsing
let body = "";
res.body.on("data", (c) => (body += c));
res.body.on("end", () => JSON.parse(body));

// Pattern C: low-level node:http call without zlib

The fix is to either use res.json() on a client that auto-decompresses, or to gate on Content-Encoding and run through zlib.gunzip / zlib.inflate / zlib.brotliDecompress before parsing.

Environment

• OpenClaw: 2026.5.12 (f066dd2)
• Node: v22.22.2
• OS: macOS (Darwin), launchd-managed gateway service
• Provider: github-copilot, model claude-opus-4.7
• Channel: signal-cli (one of several active plugins)

Workaround in place

Until this is fixed I'm running with a --require shim that forces Accept-Encoding: identity on all global fetch / undici.fetch calls. Happy to share the shim if useful for triage.