dsh-mcp-client: multi-MB base64 image results throw RangeError (V8 regex stack) and images silently degrade

[buludebin]

Summary

@deepseek-ai/dsh-mcp-client rejects large image content blocks with
RangeError: Maximum call stack size exceeded. The tool result then degrades to a
text placeholder and the model never sees the image.

Affects 0.2.1-rc.5 and 0.2.2-rc.1 (verified by unpacking both npm tarballs).

Where

packages/mcp-client → lib/index.js (published as @deepseek-ai/dsh-mcp-client):

// line 81
const CANONICAL_BASE64 = /^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$/;

// line 271 - throws on multi-MB input
if (!CANONICAL_BASE64.test(block.data)) throw new Error("the image data is not canonical base64");

// line 273 - same guarantee, linear time
if (data.toString("base64") !== block.data) throw new Error("the image data is not canonical base64");

Repro

An MCP server returns an image content block whose data is a ~5 MB base64 payload
(in our case a QQ animated GIF relayed through an MCP tool).
CANONICAL_BASE64.test(data) throws RangeError: Maximum call stack size exceeded.

The error is caught upstream, so instead of failing loudly the tool result becomes:

[image unavailable: image/gif; Maximum call stack size exceeded; raw image data remains available to programmatic callers]

Static screenshots (100-300 KB) go through fine, so the failure is purely
size-dependent. Any MCP server returning large images is affected; it is not
specific to one plugin or one MIME type. An oversized PNG/JPEG hits it too.

Cause

The nested quantifier (?:[A-Za-z0-9+/]{4})* plus an optional tail makes the V8
regex engine recurse once per repetition. For subject strings in the multi-MB range
that exceeds the call stack.

Suggested fix

Drop the regex check. Line 273 already validates exactly the same property by
round-tripping the decode (Buffer.from(data, "base64").toString("base64") !== data),
which is linear and cannot blow the stack. Removing line 271 keeps the guarantee and
fixes every oversized image regardless of MIME type.

Happy to send a PR if that is wanted.

[PerryLink]

Confirmed: the regex fails locally on a 5 MB payload.

packages/mcp/mcp-client/src/tools.ts:75 is the CANONICAL_BASE64 pattern; decodeImage tests it at :363-365, then does the round-trip at :366-369. In a local Node run with a 5 MB buffer (6,990,508 base64 chars), CANONICAL_BASE64.test(s) throws RangeError: Maximum call stack size exceeded; a variant with one bad trailing char throws the same way. So the failure is size-driven, not MIME-driven.

The round-trip at :366-369 checks the same property in linear time and cannot overflow, so deleting :363-365 keeps the guarantee. Keeping both is the bug.

Same pattern exists in packages/acp/acp/src/content.ts:19, used at :52 — the ACP image path has the same ceiling, so a PR should fix both.

Yes to the PR: remove the regex test, keep the round-trip, and add a test with a few-MB payload so the regression stays visible.

I only ran the regex locally; no MCP server round trip here.

You can hand this to an AI assistant to prepare that two-file patch.