[Bug]: terminal history can grow without a byte bound and repeatedly rewrites the full log

[tarik02]

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. Open a terminal through T3 Code.

2. Run a process that frequently emits carriage-return redraws without newlines:

   while true; do
     printf '\r%s' "$(date +%s%N)"
   done

3. Leave it running and observe the corresponding terminal history file under the T3 userdata logs directory.

4. Observe that:

   • the file continues growing despite the configured line limit;
   • persistence repeatedly rewrites the accumulated file;
   • write volume increases as the history file becomes larger.

Many TUI apps can cause similar behavior since they often render without doing \n or even \r ever.

Expected behavior

• Terminal history should have a byte-based upper bound that also handles output without newlines.
• Normal PTY output should persist only newly sanitized output, preferably through ordered and coalesced append writes.
• Full-file truncation should happen only when enforcing the size cap or explicitly clearing, restarting, or resetting a terminal.
• Existing terminal history files should remain readable or be migrated safely.
• ANSI sanitization and per-terminal output ordering must remain unchanged.

Actual behavior

Terminal history is capped by newline count rather than file size. Redraw-heavy programs that primarily emit carriage returns (\r) can therefore grow the history file without a practical byte limit.

For each PTY output update, the server queues the complete accumulated history and later truncates and rewrites the entire log file. As the file grows, a small continuous output stream causes increasingly large and frequent disk writes.

Impact

Minor bug or occasional failure

Version or commit

main@2433f4c1c01cf9e9eca983c9aeec375524e29273

Environment

Linux 6.18.44 #1-NixOS SMP PREEMPT_DYNAMIC Sun Aug 9 18:25:30 UTC 2026 x86_64 GNU/Linux

Logs or stack traces

https://github.com/user-attachments/assets/5bb374fe-ab8f-4059-b2ab-608937814d1b

Screenshots, recordings, or supporting files

No response

Workaround

No response

[tarik02]

fix attempt: #7938