MoonshotAI / MoonshotAI/kimi-code

Read tool status message omits `MAX_BYTES` cap when `MAX_LINES` is also hit

Open
#94 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
TypeScript
Stars
7.5k
Forks
1.2k
Avg merge
11h 53m
Merged PRs (30d)
350

Description

What version of Kimi Code is running?

0.3.0

Which open platform/subscription were you using?

Kimi Code

Which model were you using?

No response

What platform is your computer?

Debian(WSL)

What issue are you seeing?

When reading a file that exceeds both the MAX_LINES and MAX_BYTES_KB limits, the <system> status tag in the tool result only reports the line limit. The byte limit is silently omitted even though it was also triggered.

For example, the status might say:

<system>... Max 1000 lines reached.</system>

But it does not mention that MAX_BYTES was also hit, which could mislead the model into thinking only the line cap mattered.

What steps can reproduce the bug?
  1. Prepare a file that exceeds both MAX_LINES (1000) and MAX_BYTES_KB (100 KB) limits. For example, a file with 1001 lines where each line is very long (e.g., 120+ characters).

  2. Use the Read tool to read this file.

  3. Inspect the wire.jsonl file — in the tool result's <system> status tag, you will see:

    <system>... Max 1000 lines reached.</system>
    

    But not the Max 102400 bytes reached. message, even though the byte limit was also hit.

The root cause is in packages/agent-core/src/tools/builtin/file/read.ts: the limit checks are chained with else if, so when both maxLinesReached and maxBytesReached are true, only the first branch executes.

What is the expected behavior?

Both limits should be reported independently when both are triggered:

<system>... Max 1000 lines reached. Max 102400 bytes reached.</system>

The EOF message ("End of file reached.") should only appear when neither truncation limit was hit.

Additional information

The fix is straightforward — change else if to independent if statements and tighten the EOF condition. I have a branch ready and can open a PR once this issue is triaged.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in packages/agent-core/src/tools/builtin/file/read.ts and inspect the chained limit checks that build the tool status message. Reproduce the case with a file exceeding both 1000 lines and 100 KB, then inspect wire.jsonl. Done means the status reports both caps and shows the EOF message only when neither limit is hit.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.