fix(tui): sort child sessions by created time, not session ID

[Zagoshipda]

Issue for this PR

Closes #42905

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

session.child.first (Ctrl+X+Down) and the Left/Right child cycle sorted sibling sessions by session ID string. Session IDs are descending-encoded timestamps that wrap around at 2^48, so once the encoding wraps the ID order no longer matches creation order and "first child" lands on an old subagent instead of the newest.

The fix sorts children() in packages/tui/src/routes/session/index.tsx by time.created descending instead of by session ID. This is the ordering the ID sort was already encoding — "first child" keeps meaning newest-created, but is now stable across the wrap. The footer (N of M) counter already sorts by time.created ascending, so navigation and the counter stay consistent (Ctrl+X+Down lands on M of M).

How did you verify your code works?

• Reproduced the wrap: session IDs are ~current where current = timestamp_ms * 0x1000 + counter, truncated to 48 bits. The last wrap occurred at 2026-08-14 11:19:55 UTC.
• Checked against real session data: in an 829-child session spanning the wrap, the smallest-ID child was created minutes before the wrap while the actual newest child ranked ~756th in ID order; the new sort puts the newest-created child first.
• bun typecheck passes in packages/tui.

Screenshots / recordings

Not included — this changes which session navigation lands on, not how the UI looks, so there is nothing visual to capture.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential duplicate PR found:

• fix(tui): redo and child session ordering across id wrap #42590: fix(tui): redo and child session ordering across id wrap
  fix(tui): redo and child session ordering across id wrap #42590

  Why it's related: This PR also addresses child session ordering issues related to the timestamp ID wrap that occurs at 2^48. Both PRs are fixing the same underlying problem with session ID encoding and creation time ordering in the TUI navigation.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[Enough1122]

AI code review — automated review for reference; please use your judgment.

1. packages/tui/src/routes/session/index.tsx:211 — b.time.created - a.time.created produces NaN if either session lacks time.created (synthetic/imported sessions), and NaN comparators make sort order implementation-defined and flicker-prone across re-renders — guard with (b.time.created ?? 0) - (a.time.created ?? 0).

2. packages/tui/src/routes/session/index.tsx:211 — no tie-breaker: two children created in the same millisecond (parallel subagents spawned together) swap ordering nondeterministically between memo recomputations; appending || (a.id < b.id ? -1 : a.id > b.id ? 1 : 0) keeps the list visually stable while preserving the new time-based intent.

3. Nit — worth one word in the PR body that this flips to newest-first (descending); anyone scanning the diff sees only a comparator change and may assume ascending was kept.

Overall: right fix — ID-based ordering scattered subagent runs randomly whenever ID prefixes didn't align with creation sequence. With the two guards above this is solid. Thanks!

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.