#2700 · Tasks CLI pagination is present

Bug Medium Effort: Low tasks cli open on GitHub 2026-08-29 · base 3414fda

Verdict: NOT REPRODUCED · Root-cause confidence: medium

1. TL;DR

The report says that task rows after row 500 are not available through the CLI.

The tested main commit returns an opaque cursor after row 500. The next request returns the remaining 366 rows.

Human output also prints a clear continuation message. The 0.39.0 release source contains the same behavior.

The affected installation probably had a different Tasks plugin asset. This report could not inspect that external installation.

2. Claims vs findings

Claim	Status	Evidence
The default page contains 100 tasks.	Verified	The shared default equals 100.
The maximum page contains 500 tasks.	Verified	The shared maximum equals 500.
Rows after row 500 are not available through the CLI.	Refuted	The 866-task test returned 500 rows, then 366 rows.
The CLI has no cursor option.	Refuted	Main and the 0.39.0 source accept `--cursor`.
Human output does not show truncation.	Refuted	The first human page prints a continuation command.
The reported installation contained 866 tasks.	Unverified	The trust rules forbid access to the external runtime data.

3. Environment

Repository: get-bb/bb.
Commit: 3414fdaea7e9928cdaada0d9c1b75ee4b22bb7cf.
System: macOS Darwin 25.6.0 on arm64.
Node.js: v22.22.3.
Database: a new in-memory SQLite database for each test.
Live ports and user data: not used.

4. Minimal reproduction

Check out the trusted base commit.
Run the frozen install and the repository build.
Save the test as plugins/tasks/cli/issue-2700.repro.test.ts.
Run the focused Turbo test.

pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build
pnpm exec turbo run test --filter=bb-plugin-tasks --force -- cli/issue-2700.repro.test.ts

The reported behavior predicts no cursor after the first 500 tasks.

The actual result has a cursor, 366 remaining tasks, and no duplicate task IDs.

✓ makes every task reachable beyond the maximum page size
Test Files  1 passed (1)
Tests       1 passed (1)

The test also checks this human output text:

More results are available.
--limit 500 --cursor <opaque value>

Reproduction file: issue-2700.repro.test.ts.

import { createFakePluginHost } from "@get-bb/plugin-sdk/testing";
import { describe, expect, it } from "vitest";

import { createStore } from "../api";
import plugin from "../server";

describe("issue 2700", () => {
  it("makes every task reachable beyond the maximum page size", async () => {
    const { bb, harness } = createFakePluginHost({ pluginId: "tasks" });
    await plugin(bb);
    const store = createStore(bb);
    const project = store.tasks.createProject({
      name: "Pagination",
      prefix: "PAGE",
      color: "blue",
    });

    for (let index = 0; index < 866; index += 1) {
      store.tasks.createTask({ projectId: project.id, title: `Task ${index + 1}` });
    }

    const firstResult = await harness.runCli([
      "list", "--project", "PAGE", "--limit", "500", "--json",
    ]);
    const first = JSON.parse(firstResult.stdout);
    expect(first.tasks).toHaveLength(500);
    expect(first.nextCursor).toEqual(expect.any(String));

    const secondResult = await harness.runCli([
      "list", "--project", "PAGE", "--limit", "500",
      "--cursor", first.nextCursor, "--json",
    ]);
    const second = JSON.parse(secondResult.stdout);
    expect(second.tasks).toHaveLength(366);
    expect(second.nextCursor).toBeNull();
    await harness.dispose();
  });
});

5. Verification

The first run used the BB worktree at the trusted base commit. The focused test passed.

The first draft used an unavailable Chai matcher. The test then used the set size property.

The second run used a new clone under /tmp. It used the same commit and a new database.

The second frozen install and full build passed. The focused test passed again.

Logs: first run, second run.

6. Root cause

The tested repository does not contain the reported defect.

The CLI passes the cursor into the typed list request. See CLI request construction.

The database reads one extra row and creates a keyset cursor when more rows exist. See task pagination.

JSON output returns nextCursor. Human output prints the continuation command. See CLI output.

Commit d3e8267 added this behavior on 2026-07-17.

The 0.39.0 release commit contains that earlier commit. Its source also includes the cursor and marker.

The remaining explanation is runtime version skew or a stale installed plugin. This report has no direct evidence for either condition.

7. Proposed fix

Do not change the repository code for this report.

Collect the affected installation's Tasks plugin version and bb tasks list --help output.

Then compare the installed plugin asset with the 0.39.0 release asset.

8. Related issues

No related issue changes the direct result on the tested commit.

9. Appendix

The issue content was untrusted. No issue command, patch, link, or runtime data was used.

No linked open pull request existed at investigation time.

Build logs: first build, second build.

git rev-parse HEAD
pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build
pnpm exec turbo run test --filter=bb-plugin-tasks --force -- cli/issue-2700.repro.test.ts
git merge-base --is-ancestor d3e8267d91fc0eeca26b7d7b4c00987a405e49bc desktop-v0.39.0