Warp freezes at 100% CPU / 19GB RAM in code review diff view

[shkumbinhasani]

Describe the bug

After running for ~2 days, Warp locks up completely — 100% CPU on the main process and 19.1 GB physical memory footprint. The app becomes unresponsive and must be force-killed.

A 5-second CPU sample shows the main thread is stuck in a tight loop inside the code review / diff view reactivity system:

flush_effects → subscribe_to_model (CodeReviewView::create_code_review_model_with_global_buffer)
  → RefCounts::inc_entity / RefCounts::dec_model

This looks like a runaway ref-counting cycle in warpui_core's effect/subscription system — inc_entity and dec_model are spinning on the main thread with no exit, burning 100% CPU indefinitely.

To reproduce

1. Open Warp and use the built-in code review / diff view features
2. Leave Warp running for an extended period (~2 days in my case)
3. Eventually, Warp becomes completely unresponsive
4. ps aux shows the process at 100% CPU; sample confirms the stack trace above

Exact trigger is unclear — it may be related to a long-lived session with code review state accumulating over time.

Expected behavior

Warp should remain responsive regardless of session duration, and the code review model subscriptions should not enter an infinite ref-counting loop.

Screenshots, videos, and logs

CPU Sample (top of call graph)

Call graph:
    2833 Thread_6566   DispatchQueue_1: com.apple.main-thread  (serial)
      2832 main → warp::run → warp::run_internal → NSApplication run
        1623 flush_effects → subscribe_to_model (CodeReviewView) → RefCounts::inc_entity (tight loop)
        272  subscribe_to_model → RefCounts::dec_model (tight loop)
        43   memmove (large data shuffling)

Process stats at time of capture

PID:                680
CPU:                100% (sustained)
Physical memory:    19.1 GB (peak: 19.1 GB)
Threads:            68
Open files/sockets: 374
Uptime:             ~51 hours (since Sun Mar 15 19:14)

Full 5-second CPU sample file (652 KB) available on request.

Operating system and version

macOS 26.3 (25D125), ARM64

Shell Version

zsh (version retrieved separately)

Current Warp version

0.2026.03.04.08.20.03

Regression

Not sure — first time encountering this specific freeze.

Additional context

• Machine: Apple Silicon, 14 cores, 24 GB RAM
• The 19.1 GB footprint suggests a memory leak compounding alongside the CPU spin — possibly the ref-count loop is also allocating or retaining objects each iteration
• The hot path is entirely within warpui_core::core (the reactivity/effect system), not in rendering or I/O
• Killing with kill <pid> (SIGTERM) worked; no need for SIGKILL

Does this block you from using Warp daily?

Yes — requires force-killing and restarting Warp, losing all session state.

Is this an issue only in Warp?

Yes

[kevinyang372]

Hi @shkumbinhasani. Sorry for the experience here. This is top priority for us to fix. Do you mind sharing the raw process sample and I could take a look?

[shkumbinhasani]

Hi @kevinyang372, here are the full diagnostic files:

https://gist.github.com/shkumbinhasani/f13da34470939f0cd638d44d2c02cae4

Includes:

• warp_sample.txt — 5-second CPU sample (the main one)
• warp_openfiles.txt — open file descriptors / sockets
• warp_threads.txt — thread listing
• system_info.txt — system & process summary

Let me know if you need anything else.