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

Aberta Para iniciantes
  • Algo errado?
#5,526 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
72/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
backend

Direção de pesquisa

Comece por src/sequentialthinking/lib.ts, especialmente formatThought e a lógica de MAX_BOX_ROWS, e depois inspecione o esquema de branchId em src/sequentialthinking/index.ts:110. A issue sugere contar as linhas do cabeçalho no limite de linhas da caixa ou adicionar um limite ao comprimento da entrada. Confirme que o limite escolhido é aplicado e adicione ou atualize testes específicos para IDs de branch longos; o trabalho estará concluído quando eles não puderem contornar o limite pretendido.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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).
Linguagem predominante
TypeScript
Estrelas
91.9k
Forks
11.9k
Merge médio
3h 10min
PRs com merge (30d)
178

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de modelcontextprotocol/servers

Todas as issues de modelcontextprotocol/servers

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.