fix(tools): lower listSessions default limit from 20 to 10 (R2 F14)#40
Conversation
R2 audit finding F14 (2026-05-04, Intent Solutions pilot): Claude Code applies a 25k-token cap on MCP tool responses. `listSessions` responses with verbose `execution_data` per session can approach or exceed this cap at the previous default of 20; the R2 audit empirically observed responses near the cap dropping fields or sessions without an explicit error surfaced to the agent. Plugin-side mitigation: lower the default from 20 to 10. With verbose `execution_data` fields, 10 sessions has headroom against the 25k cap; agents can still request higher explicitly via `limit`, but the safer default avoids the silently-dropped-result class of bug. Cross-references: - R2 fork issue #24 (multi-finding bundle: F14 + F16 + F17 read-side shape consistency) - R2 upstream issue kobiton#35 - R3 § 4 Bundle 1 (#31) — F42 server-sent list_changed notifications + cursor-based pagination would obviate this entirely; the default-lowering here is the plugin-side stopgap until the server adopts those primitives. F16 (field divergence between getSession + getSessionArtifacts) and F17 (xium URL asymmetry) are server-side; tracked via upstream #35. Validation: - `pnpm run validate` passes - `pnpm test` passes (22 tests) - `validate-skills-schema.py --enterprise` passes with 91/100 average Signed-off-by: jeremylongshore <jeremylongshore@users.noreply.github.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the limit parameter in tools/sessions.yaml, reducing the default value from 20 to 10 to mitigate potential token truncation issues. The reviewer suggests refining the description to remove historical context and adding a maximum property to the schema to provide a hard guardrail against exceeding the 25k-token response cap.
| description: >- | ||
| Maximum number of sessions to return. Default lowered from 20 to 10 | ||
| to stay within the 25k-token plugin response cap; sessions with | ||
| verbose `execution_data` can otherwise overflow and silently | ||
| truncate at the client. Raise carefully and verify response size. | ||
| default: 10 |
There was a problem hiding this comment.
The description includes historical context ("Default lowered from 20 to 10") which is generally unnecessary for the tool's runtime definition and may become outdated. Additionally, since the 25k-token cap is a known constraint that causes silent truncation, relying on the agent to "verify response size" is not an actionable instruction for an LLM. It is recommended to include a maximum property in the schema to provide a hard guardrail against known failure conditions.
description: >-
Maximum number of sessions to return. Defaults to 10 to stay within
the 25k-token response cap. Large responses with verbose execution
data may be truncated by the client if the limit is set too high.
default: 10
maximum: 201 participant
Closes R2 F14 plugin-side. Server-side full fix at upstream
kobiton/automate#35.Summary
R2 audit finding F14 (2026-05-04): Claude Code applies a 25k-token cap on MCP tool responses;
listSessionsresponses with verboseexecution_dataper session can approach or exceed this cap at the previous default of 20. The R2 audit empirically observed responses near the cap dropping fields or sessions without an explicit error surfaced to the agent.Lowering the default from
20→10. With verboseexecution_datafields, 10 sessions has headroom against the 25k cap. Agents can still request higher explicitly vialimit, but the safer default avoids the silently-dropped-result class of bug.Files
tools/sessions.yaml— single field change onlistSessions.inputSchema.properties.limit.default+ expanded description noting the cap rationale.Validation
pnpm run validatepassespnpm testpasses (22 tests)validate-skills-schema.py --enterprisepasses with 91/100 averageRelationship to other R2 + R3 work
kobiton/automate#35list_changednotifications + cursor-based pagination would obviate this entirely. The default-lowering here is the plugin-side stopgap until the server adopts those primitives.F16 (field divergence between
getSession+getSessionArtifacts) and F17 (xium URL asymmetry) are server-side; tracked via upstream #35.Notes
DCO sign-off included.