mcpx(model+scripting): OpenAI-compatible providers buffer response bodies whole — io.ReadAll uncapped, and the error path embeds the entire body in the error string #4354

Summary

mcpx's two OpenAI-compatible model providers buffer a provider's entire HTTP response body with no size cap, and on a non-2xx response they embed that whole body in the returned error string:

• pkgs/mcpx/internal/model/openai.go:123 — respBody, err := io.ReadAll(resp.Body) in OpenAIProvider.Generate; the error path at :128-131 formats the full body into the error (strings.TrimSpace(string(respBody)), no truncation).
• pkgs/mcpx/internal/scripting/provider.go:121 — the twin code in OpenAICompatibleProvider.Complete; the error path at :125-128 likewise embeds the full body.

The baseURL of both providers is configuration, not a constant: the model layer's own doc comment (openai.go:17-20) says the same code serves "OpenAI itself, a company gateway, LiteLLM, Ollama and LM Studio", and the scripting provider lists Ollama / local Qwen / vLLM / LM Studio. A misbehaving, compromised, or simply wrong endpoint (e.g. a proxy returning a large HTML error page, or a local server gone wrong) can therefore make the daemon allocate an arbitrarily large body in memory — and on the error path, produce an arbitrarily large error string that callers log and surface.

Contrast inside the same codebase: internal/mcpclient/http.go:167 and sse.go read non-2xx bodies through io.LimitReader(resp.Body, defaults.HTTPErrorBodyLimit) (internal/defaults/defaults.go:400-402, "bounds how much of a non-2xx body is read"), and the daemon's own request paths use http.MaxBytesReader / io.LimitReader throughout. These two provider implementations are the un-capped outliers. (Distinct from #4282, which is the mcpclient Send success-path fallback in a different package; this issue is the two model-provider implementations and their error embedding.)

Evidence (verified this run, main bc1bdce)

• Source files md5-identical between sandbox main bc1bdce and the laptop probe tree: model/openai.go b588dd091baea938ff8492476150e2e0, scripting/provider.go 898d9cd168c60971538331c917fa2731.
• Laptop probe ~/git/fleet/probe-2026-11-02-laneA-modelbody/ (detached worktree of the repo; probe tests only, in-package, against httptest servers):
  • internal/model: server returns HTTP 500 with a 33,554,432-byte body of x → Generate returns an error of length 33,554,473 bytes — the entire body, buffered and embedded. A 200 response with a 32 MiB non-JSON body is likewise read in full before the JSON parse error is produced.
  • internal/scripting: same 500/32 MiB setup → Complete returns an error of length 33,554,466 bytes.
  • Both probes pass in the sense that they demonstrate the un-capped behaviour (go test -run TestProbeHuge -count=1 -v, both packages).

Why it matters

• Memory: one provider response can force an unbounded allocation in the long-lived mcpx daemon; nothing else in the response path (timeout aside) bounds it — the client timeout bounds duration, not bytes, and a fast local endpoint can deliver gigabytes within it.
• Log/surface bloat: the non-2xx path copies the whole body into an error string that callers fall back on, log, and may return to users — a 33 MB "error message" in this probe, unbounded in principle.
• The house pattern already exists (LimitReader + defaults.HTTPErrorBodyLimit for error bodies); these two sites were simply never brought under it.

Acceptance criteria

• Both providers read response bodies through a bounded reader with a stated cap (per-path if success and error bodies warrant different bounds; the error body must never exceed a small bound such as defaults.HTTPErrorBodyLimit in the produced error string).
• Exceeding the success-path cap produces a clear error naming the provider and the cap, not a silent truncation that then fails JSON parsing with a misleading message — or, if truncation is chosen, the error says the response was truncated at the cap.
• Regression tests in internal/model and internal/scripting: an httptest provider returning an oversized error body yields an error whose length is bounded by the cap (plus fixed overhead); an oversized success body is refused/truncated per the chosen contract; normal small responses (success and error) behave exactly as before.
• go test ./internal/model/ ./internal/scripting/ -count=1 passes (package-scoped per pkgs/mcpx/internal/AGENTS.md).