[BUG] Cannot scroll to beginning of long conversations (message limit hardcoded to 100) (#6138)

[CasualDeveloper]

Problem

In long conversations, users cannot scroll back to the first message. The TUI only loads the most recent 100 messages, with no way to access earlier history.

Root Cause

The message fetch limit is hardcoded to 100 in sync.tsx:348:

sdk.client.session.messages({ sessionID, limit: 100 })

Proposed Solution

Make the limit configurable via tui.message_limit in opencode.json:

{
  "tui": {
    "message_limit": 500
  }
}

• Default: 100 (preserves current behavior)
• Range: 1-10000

Implementation

• Add message_limit to TUI config schema in config.ts
• Use config value in sync.tsx with fallback to 100

[CasualDeveloper]

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

[rekram1-node]

i think the better solution we want is to paginate the messages with virtualized scrolling

[CasualDeveloper]

@rekram1-node I’m mostly Java/backend and not TypeScript/UI, so I needed to look up what you meant lol.

but yeah makes sense to me now that pagination + virtualized scrolling is the real fix. though I have to admit that I'd need to lean hard on Claude 4.5 Opus to tackle that. I opened a follow‑up issue, if you want to review.

This PR is just a quick band‑aid for now.

[ozataman]

Keep running into this issue in complex codebases/when using big models. +1 on needing a solution. I'd recommend not baking in a hard limit on the history; that's just another time bomb waiting to happen on the next change needed.

[ozataman]

Also, is it possible this is causing miscalculation of context usage/remaining context? I keep running into context exceeded errors with ChatGPT-5.2-Codex xhigh even as it shows substantial amount of context remaining.

Furthermore, it seems like even the /export function can't recover the full history and starts mid-way through the full thread.

I had to write an ad-hoc script to reassemble content from /store as even export can't provide the full history. Highly recommend this issue is prioritized - sessions literally lose data if they get long enough.

[CasualDeveloper]

@ozataman There's another issue opened at #6548 to implement the pagination feature that Aiden recommended that would also remove the limit while having better performance than this feature because it doesn't have to load every message in the session at once, but still wip I think