[Bug]: Degraded performance of the remote webapp on large threads.

[akhmerov]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run T3 Code in remote/headless server mode.
   In my case this is t3 start --host 127.0.0.1 --port 51000 --no-browser behind a private HTTPS/WSS route, but the failure appears to be in the T3 server before proxying matters.
2. Use T3 remotely over a constrained or lossy network.
3. Open an active thread with a large amount of accumulated activity/tool output/attachments.
4. Force a browser reconnect, or wait for an intermittent disconnect/reconnect.
5. Observe that the client repeatedly reconnects or shows disconnect/reconnect churn.

Expected behavior

A reconnect to an existing large thread should recover without flooding the WebSocket.

Heartbeat/control frames should not get stuck behind a large full-thread snapshot. The server should either stream/paginate/lazy-load large thread history or apply backpressure so a slow client path does not create a large outbound queue.

Actual behavior

• The webapp shows a constant disconnected/connected message.
• The thread takes a long time to load.
• Submitting new messages works but the webapp doesn't refresh.

Impact

Major degradation or frequent failure

Version or commit

0.0.24

Environment

Ubuntu 24.04 server, node v25.8.2

Logs or stack traces

Sanitized metadata-only diagnostic excerpt:

out_large bytes=6144596 bufferedBefore=0 tags=["_tag=Chunk"]
out_large bytes=7303819 bufferedBefore=0 tags=["_tag=Chunk"]
out_large bytes=5585838 bufferedBefore=7319163 tags=["_tag=Chunk","type=image","name=image.png"]
out_large bytes=28536607 bufferedBefore=12898648 tags=["_tag=Chunk"]
out_large bytes=38591063 bufferedBefore=41430865 tags=["_tag=Chunk","type=image","name=image.png"]
out_large bytes=15 bufferedBefore=72697864 tags=["_tag=Pong"]

Screenshots, recordings, or supporting files

No response

Workaround

Start a fresh thread or avoid reopening very large historical threads over weak remote links.

Archiving heavy old threads may reduce navigation/shell pressure, but reopening the large thread still triggers the full-detail snapshot.

A product-side fix likely needs one or more of:

• paginate/lazy-load thread messages and activities instead of sending all history in the initial subscribeThread snapshot
• cap/truncate initial snapshot activity payloads and let the client request older history
• implement server-side WebSocket backpressure handling so large payloads do not queue unboundedly ahead of heartbeat/control frames

[akhmerov]

Correction: it appears that all unarchived threads create websocket congestion.