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

Aperta Adatta ai principianti
  • Qualcosa non va?
#5,526 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend

Direzione di ricerca

Inizia da src/sequentialthinking/lib.ts, in particolare da formatThought e dalla logica di MAX_BOX_ROWS, poi esamina lo schema di branchId in src/sequentialthinking/index.ts:110. L’issue suggerisce di conteggiare le righe dell’intestazione nel limite di righe del riquadro o di aggiungere un limite alla lunghezza dell’input. Verifica che il limite scelto venga applicato e aggiungi o aggiorna test mirati per gli ID di ramo lunghi; il lavoro è completato quando non possono aggirare il limite previsto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).
Lingua principale
TypeScript
Stelle
91.9k
Fork
11.9k
Merge medio
3h 10m
PR unite (30g)
178

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/servers

Tutte le issue di modelcontextprotocol/servers

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.