sequentialthinking: long branchId values bypass the log-box row cap via uncounted header lines (same shape as the #5433 fix) #5526

Which server?

sequentialthinking (@modelcontextprotocol/server-sequential-thinking)

Server version

checked at monorepo commit 6cfff62

How did you run the server?

Not applicable (a repository-level report)

Transport

stdio

Protocol era

Modern (2026-07-28)

MCP client and version

n/a (repository-level report; code reading only)

Operating system and runtime

No response

Server configuration

Not applicable — no server was run; code reading only.

Steps to reproduce

Summary
A small consistency gap in the sequentialthinking server (src/sequentialthinking, checked at monorepo commit 6cfff62), raised as a minor correctness/robustness note only. The effect is confined to the calling client's own connection, and I am not framing this as a security issue.

Background
The project has already capped this component's growth in two places:

• Thought count: capped at 1,000 (lib.ts:64, enforced at lib.ts:232-242), from Huge memory occupation by sequentialthinking MCP #2912, and documented.
• Log amplification: the stderr thought box caps its body rows (MAX_BOX_ROWS), from sequentialthinking: the multi-line thought box grows quadratically and can exhaust memory #5433.

Steps (code reading, no server run):

1. Read formatThought in lib.ts and note the comment that the box's header lines are explicitly not counted toward that row budget.
2. Read the input schema in index.ts:110 — branchId is z.string().optional() with no length cap — and index.ts:79 for thought, likewise uncapped.
3. Grep the component for .max(: none exists anywhere in the component, so per-item sizes are the one dimension left uncapped after Huge memory occupation by sequentialthinking MCP #2912 (count) and sequentialthinking: the multi-line thought box grows quadratically and can exhaust memory #5433 (log rows).
4. Note that branch names are echoed in every result's branches list, so a single very long branchId is re-emitted on every later call in the branch, and each retained thought is stored in full in the history (up to the 1,000-thought cap, lib.ts:221).

Expected behavior

The log-box row cap should bound the whole box, including its header lines, so a long branchId cannot bypass it; equivalently, branchId (and possibly thought) length should be capped in the input schema, consistent with the caps the component already has. Either fix is small; the first seems more in the component's existing style.

Actual behavior

The gap

• The box's header lines are explicitly not counted toward that row budget (per the comment in formatThought in lib.ts), and branchId is rendered in full in the header of every subsequent thought in the same branch.
• branchId itself has no length cap (index.ts:110: z.string().optional()), and neither does thought (index.ts:79). In fact no .max( exists anywhere in the component (grep-verified), so per-item sizes are the one dimension left uncapped after Huge memory occupation by sequentialthinking MCP #2912 (count) and sequentialthinking: the multi-line thought box grows quadratically and can exhaust memory #5433 (log rows).
• Branch names are also echoed in every result's branches list, so a single very long branchId is re-emitted on every later call in the branch, and each retained thought is stored in full in the history (up to the 1,000-thought cap, lib.ts:221).
  So the header passthrough reproduces, through the header, the same output-amplification shape that sequentialthinking: the multi-line thought box grows quadratically and can exhaust memory #5433 closed for the body.

This is a minor correctness/robustness note only. The effect is confined to the calling client's own connection, and I am not framing this as a security issue.

Logs or error output

Not applicable — code reading only; no server was run, so there are no logs or error output.

Already prototyped a fix?

No diff attached, and no fix was prototyped locally, per this repository's contribution model. Suggestion: either cap branchId (and possibly thought) length in the input schema, consistent with the caps the component already has, or count header lines toward the box's row budget. Either fix is small; the first seems more in the component's existing style.

Reporter: Tomoki Murota, CISSP

Before you submit

• I searched existing issues and this is not a duplicate.
• This is not a security vulnerability report (those go through the private advisory form).