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

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#5,526 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
backend

Rechercherichtung

Beginne mit src/sequentialthinking/lib.ts, insbesondere mit formatThought und der MAX_BOX_ROWS-Logik, und untersuche dann das branchId-Schema in src/sequentialthinking/index.ts:110. Das Issue schlägt vor, die Kopfzeilen auf das Zeilenbudget der Box anzurechnen oder eine Eingabelängenbegrenzung hinzuzufügen. Bestätige, dass die gewählte Begrenzung durchgesetzt wird, und füge gezielte Tests für lange Branch-IDs hinzu oder aktualisiere sie; fertig ist es, wenn sie die vorgesehene Begrenzung nicht umgehen können.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug server-sequentialthinking v2
Which server?

sequentialthinking (@modelcontextprotocol/server-sequential-thinking)

Server version

checked at monorepo commit 6cfff622fb8eb41e2504340d5a6105d34094143c

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 6cfff622fb8eb41e2504340d5a6105d34094143c), 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 #2912, and documented.
  • Log amplification: the stderr thought box caps its body rows (MAX_BOX_ROWS), from #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 #2912 (count) and #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 #2912 (count) and #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 #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).
Vorherrschende Sprache
TypeScript
Sterne
91.9k
Forks
11.9k
Ø Merge
3 Std. 10 Min.
Gemergte PRs (30 T.)
178

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/servers

Alle Issues in modelcontextprotocol/servers

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.