feat(tui): add session_list_limit for session picker (#6137)

[CasualDeveloper]

Summary

• Add configurable session_list_limit for the session picker (default 150)
• Apply limit only when not searching (search continues to use server-side limit 30)
• Regenerate SDK types and openapi.json

Notes

• message_limit has been removed; cursor-based pagination (feat(session): bi-directional cursor-based pagination (#6548) #8535) now covers message history
• No changes to sync.tsx to avoid pagination conflicts

Testing

• bun run --cwd packages/opencode typecheck

Closes #6137 and maybe also #4918

[Copilot]

Pull request overview

This PR adds a configurable message_limit option to control the number of messages loaded per session in the TUI. The default value remains 100, but users can now configure it up to 10,000 messages through the config file.

• Add message_limit configuration field to TUI schema with validation constraints (1-10,000)
• Update implementation to use the configured value with fallback to 100
• Generate corresponding TypeScript type definitions

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/sdk/openapi.json	Adds message_limit field to the schema with integer constraints (1-10,000) and description
packages/sdk/js/src/v2/gen/types.gen.ts	Generated TypeScript types for the new message_limit config option
packages/sdk/js/src/gen/types.gen.ts	Generated TypeScript types with incorrect default value in documentation
packages/opencode/src/config/config.ts	Adds Zod schema validation for message_limit with proper constraints
packages/opencode/src/cli/cmd/tui/context/sync.tsx	Updates message loading to use configured limit with fallback to 100

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[CasualDeveloper]

Fixed the inconsistent default value in the SDK types (was 500, now correctly 100). Thanks Copilot!

[CasualDeveloper]

Fixed second hardcoded 100 in the message.updated event handler at line 191. Without this, new messages arriving during active sessions would trim the array back to 100, defeating the configurable limit.

[CasualDeveloper]

I have a working implementation ready - typechecks pass.

[ariane-emory]

@CasualDeveloper I also want to see this feature. I've had a half-finished PR in my pocket for a while that addresses this (and also makes the length of session_list similarly configurable) I haven't found the time to finish it and yours looks like it may be cleaner than mine.

I cordially invite you to steal anything you think might be useful from my unfinished PR: ariane-emory#43

The team may (or may not) conclude that this also resolves my original Issue on the topic, #4918.

[CasualDeveloper]

@ariane-emory Thanks for linking your PR! I've incorporated session_list_limit from your work. Kept the implementation simpler (no "none" option, proper types instead of as any casts). Added a reference to #4918 in the PR description.

[CasualDeveloper]

Re-committed with valid GPG signature. PR ready.

[CasualDeveloper]

Will continue rebasing on top of release tags as they're set.

[benitogonzalezh]

I ran this branch to solve a problem that I have (Fork an old message). Works perfect thnks!

[CasualDeveloper]

Revised: session_list_limit only

I've rebased and revised this PR to remove message_limit entirely. With cursor-based pagination merged (#8535), message_limit is now redundant and was causing conflicts in sync.tsx.

What's left

• session_list_limit config option (1-10000, default 150)
• Limits sessions displayed in the picker when not searching
• Search continues to use server-side limit of 30

Files changed

• config.ts: Added session_list_limit to TUI schema
• dialog-session-list.tsx: Added .slice() logic
• SDK types and openapi.json regenerated

No sync.tsx changes — conflicts eliminated.

cc @ariane-emory — kept your session_list_limit contribution, just without message_limit.

[ariane-emory]

@CasualDeveloper Might be prudent to revise the top/initial message and the title to accurately reflect the new state/scope of the PR? I was pretty confused when I came to look at the code and didn't see the setting named in the title.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[CasualDeveloper]

Updated the PR title/body to reflect the new scope (session_list_limit only). Thanks for the nudge, @ariane-emory!