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

オープン 初心者向け
  • 何か問題がありますか？
#5,526 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
backend

調査の方向性

まず src/sequentialthinking/lib.ts、特に formatThought と MAX_BOX_ROWS のロジックを確認し、次に src/sequentialthinking/index.ts:110 の branchId スキーマを調べてください。Issue では、ヘッダー行をボックスの行数上限に含めるか、入力長の上限を追加することが提案されています。選択した上限が適用されることを確認し、長いブランチ ID に関する対象を絞ったテストを追加または更新してください。長いブランチ ID で意図した上限を回避できなくなれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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).
主要言語
TypeScript
スター
91.9k
フォーク
11.9k
平均マージ
3時間 10分
マージ済み PR（30日）
178

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/servers のほかの issue

modelcontextprotocol/servers の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。