[Bug]: Diff highlighting workers sustain ~600% CPU on Linux

[jetersen]

Before submitting

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

Area

apps/desktop

Steps to reproduce

The minimal UI trigger is not yet isolated. This was observed in a normal desktop session with Codex threads and rendered code diffs:

1. Start T3 Code desktop on a 16-logical-CPU Linux machine.
2. Use Codex threads that produce file changes/diffs and leave the app open.
3. Observe sustained CPU usage from one T3 Code Electron subprocess.
4. Inspect that process's threads: six DedicatedWorker threads remain runnable and each consumes approximately one full core.

Restarting T3 Code clears the condition. The report includes process-level evidence to help identify the responsible component even though the precise diff/content trigger is not yet known.

Expected behavior

Diff-rendering workers should return to an idle/sleeping state after highlighting work completes. An idle or background T3 Code window should not continuously occupy six CPU cores.

Actual behavior

One T3 Code Electron subprocess sustained about 606% CPU (approximately six full cores) and used about 1.25 GiB RSS. Its main thread and compositor were mostly sleeping, while exactly six threads named DedicatedWorker were continuously runnable at 99.5-100% CPU each.

The packaged source map points to DiffWorkerPoolProvider.tsx, which constructs an @pierre/diffs worker pool using:

const cores = Math.max(1, navigator.hardwareConcurrency || 4);
const workerPoolSize = Math.max(2, Math.min(6, Math.floor(cores / 2)));

On this 16-logical-CPU system that produces exactly six workers, matching the six hot DedicatedWorker threads. The worker factory loads @pierre/diffs/worker/worker.js?worker (packaged as worker-CKmegNFP.js). This strongly suggests the sustained load is in diff syntax highlighting/rendering rather than Codex backend work.

The T3 server and Codex app-server processes were comparatively quiet (roughly 0-5% CPU). The hot process performed no meaningful disk I/O during the sample, which also argues against repository indexing or checkpoint capture.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.0.28 (fda6486233e0), Arch/CachyOS package t3code-bin 0.0.28-1

Environment

Linux x86_64, kernel 7.1.3-2-cachyos, T3 Code desktop/Electron on Wayland, 16 logical CPUs, Codex provider

Logs or stack traces

Top process over a 2.5-second /proc CPU-delta sample:

606.1% pid=4812 ppid=3558 threads=27 rss=1247MB
cmd=/opt/t3code-bin/t3code --type=zygote --no-sandbox

Hot threads over a separate 2-second sample (100%=one core):

100.0% tid=14716 state=R comm=DedicatedWorker
100.0% tid=14718 state=R comm=DedicatedWorker
100.0% tid=14719 state=R comm=DedicatedWorker
100.0% tid=14720 state=R comm=DedicatedWorker
 99.5% tid=14715 state=R comm=DedicatedWorker
 99.5% tid=14717 state=R comm=DedicatedWorker
  0.5% tid=4812  state=S comm=t3code         wchan=futex_wait
  0.0% tid=4821  state=S comm=Compositor     wchan=epoll_wait

Process status:

VmRSS:  1284864 kB
RssAnon: 1159284 kB
Threads: 27

I/O counters were effectively unchanged across the sample:

read_bytes:  30052352 -> 30052352
write_bytes: 0        -> 0

Relevant sibling processes at the same time:

5.2% T3 server (apps/server/dist/bin.mjs)
0.8% codex app-server
0.4% T3 Electron main process

The six workers had each accumulated roughly 5,346-5,467 CPU-seconds by the time of inspection.

Screenshots, recordings, or supporting files

No attachment. Process/thread samples and packaged-source correlation are included above.

Workaround

Restart T3 Code. Avoiding or closing the diff view may also help, but that has not yet been verified as a reliable workaround.