TaskList drops the newest tasks and reports the truncated count as the total

What version of Kimi Code is running?

0.37.2 (the listing logic is unchanged on current main fa9865f, refs below)

Which open platform/subscription were you using?

Kimi Code (OAuth)

Which model were you using?

kimi-code/k3

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

In a session with more than 20 background tasks, TaskList(active_only=false) returns the 20 oldest-registered tasks and silently drops the newest ones. The header reports background_tasks: 20, which is the truncated length, not the total, so there is no signal that anything is missing and no reason for the model to retry with a higher limit.

We hit this supervising Kimi Code inside Intendant (it runs Kimi Code as a managed backend): in a long resumed session, TaskList returned 20 old tasks while the just-finished subagent task and its terminal reason were absent, and the supervising agent fell back to reading checkpoint files to find out what happened.

The mechanism (same in both engines): list() iterates the task map in insertion order (registration order live, restore order after a resume) and returns mid-iteration as soon as limit fills, with ghost tasks appended after live ones. No ordering happens before the cut, so the window is "first registered", and the tasks an agent most needs, the ones that just changed state, are exactly the ones cut. The tool passes args.limit ?? 20 and formats the truncated array's length as the count.

• agent-core: https://github.com/MoonshotAI/kimi-code/blob/fa9865f/packages/agent-core/src/agent/background/index.ts#L398-L413
• agent-core-v2: https://github.com/MoonshotAI/kimi-code/blob/fa9865f/packages/agent-core-v2/src/agent/task/taskService.ts#L499-L515
• tool default + count: https://github.com/MoonshotAI/kimi-code/blob/fa9865f/packages/agent-core-v2/src/agent/tools/task/task-list/taskListTool.ts#L12-L42

What steps can reproduce the bug?

In any session, start 21 or more background tasks (the Agent tool or detached Bash both work), let the newest one finish, then call TaskList with active_only=false and no limit. The newest task is absent from the output and the header says background_tasks: 20. Equivalent at the service level:

// register 21 tasks in order, then:
service.list(/* activeOnly */ false, /* limit */ 20);
// -> the 20 oldest by registration; the newest task is not in the result

Since the schema caps limit at 100, sessions past 100 tasks cannot see recent tasks through this tool at all.

What is the expected behavior?

TaskList orders results before applying the limit (active tasks first, then most recent) so the newest state changes are always visible, and the header reports truncation, e.g. background_tasks: 20 of 34, so the model knows more exist and can raise limit.

Additional information

This looks like a small, contained fix: sort the candidates before the cut and include the total in the header, no schema changes. Happy to submit it for both engines with regression tests after approval, or v2-only if agent-core is maintenance-frozen. Not related to #667 / #2130 (live output streaming), which we're deliberately not touching.

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)

Start with packages/agent-core/src/agent/background/index.ts and packages/agent-core-v2/src/agent/task/taskService.ts, then inspect taskListTool.ts for the default limit and count formatting. Reproduce the issue with 21 tasks and TaskList(active_only=false), checking both engines. Done means recent tasks appear before the limit and the header indicates when the total exceeds the returned count, with regression coverage for the behavior.