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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#5,526 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend

Línea de trabajo

Empieza con src/sequentialthinking/lib.ts, especialmente con formatThought y la lógica de MAX_BOX_ROWS, y luego inspecciona el esquema de branchId en src/sequentialthinking/index.ts:110. El issue sugiere contar las líneas de encabezado dentro del presupuesto de filas del recuadro o añadir un límite de longitud de entrada. Confirma que se aplique el límite elegido y añade o actualiza pruebas específicas para IDs de rama largos; el trabajo estará terminado cuando no puedan eludir el límite previsto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).
Lenguaje dominante
TypeScript
Estrellas
91.9k
Forks
11.9k
Merge medio
3 h 10 min
PR fusionados (30 d)
178

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/servers

Todos los issues de modelcontextprotocol/servers

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.