tui: resume hangs at 100% CPU when a session has thousands of child sessions #57641

Summary

Resuming (opening) a session that has thousands of child subagent sessions makes the TUI spin at ~100% CPU indefinitely and never become interactive. With ~2,559 children it never recovers. With 558 or 778 children the same session opens normally. Deleting the child sessions fixes it immediately.

Environment

• opencode version: 2.0.32 (latest channel at the time; 2.1.2 was already offered)
• OS: macOS 15.8.1 (Darwin 24.6.0, x86_64)
• Terminal: Apple Terminal, TERM=xterm-256color, TERM_PROGRAM=Apple_Terminal
• Shell: /bin/zsh
• Install/channel: release install (~/.opencode/bin/opencode), latest
• Active plugins: none configured by the user (only built-in TUI plugins such as opencode.diffs, opencode.merman, opencode.latex)

Reproduction

1. Have a session with a large transcript (here: 5,809 messages / 72 MB) and more than ~2,000 child sessions created through task subagents. A real-world session had 2,575 finished children.
2. Resume it: opencode -s <session-id> (also reproduces with opencode -c, selecting it in the TUI, and opencode --standalone -s <session-id>).
3. The TUI renders the first page, then pins one core at 100% CPU and stops responding to input.

Synthetic repro without needing a real subagent run:

1. Export a session: opencode session export <id> > /tmp/parent.json.
2. Import it once as a new parent, then import ~2,600 empty child sessions with POST /api/experimental/session/import, each with info.parentID pointing at the new parent (and a fresh info.id).
3. opencode -s <new-parent-id>.

Reproducibility: 100% for us. It is not project-specific (reproduces in an empty directory) and not provider/model-specific.

Expected Behavior

The session opens to an interactive prompt, like any other session.

Actual Behavior

• While loading, the client sends 2 HTTP requests per child session: GET /api/session/{childID}/form and GET /api/session/{childID}/permission (plus paginated child lists, 200 per page). For 2,559 children that is ~5,118 requests.
• All of those requests complete in ~2 seconds (server responds in 3–40 ms each). After that the client spins forever at ~100% CPU.
• sample <pid> of the hung process shows the main thread repeatedly in setTerminalTitle → writeOut (Bun), i.e. it never drains back to the event loop. No further HTTP traffic is sent.
• The shared server stays healthy; GET /api/session/{id}, /message, /context, /diff all answer in milliseconds.
• Memory grows to ~450–580 MB RSS; the screen keeps showing the loading spinner.

Additional Context

Measured threshold (same 5,809-message parent transcript, synthetic child sessions):

Other notes:

• time_archived on the child sessions does not remove them from GET /api/session?parentID=..., so archiving is not a workaround.
• Workaround that does work: delete the child sessions (DELETE /api/session/{id} / opencode session delete <id>), keeping the parent. After deleting 2,575 children, resume went from a permanent 100% CPU to ~3–7% and the full transcript was intact.
• Data hygiene note: on this machine the DB had grown to 17 GB. A single parent's 558 children occupied 6.9 GB in session_message and 6.8 GB in the legacy part table. The child-session fan-out is the main source of DB bloat in our usage.
• The hang is client-side: --standalone (private server) reproduces identically, and the shared server logs show no errors.

Relevant log lines during load (client):

message="cli starting" version=2.0.32 args="[\"-s\",\"<session-id>\"]" role=cli
message="event stream connected" component=client role=cli
# then ~5k requests:
GET /api/session/<child>/form -> 200
GET /api/session/<child>/permission -> 200
# then no further output; process stays at ~100% CPU