Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

On Windows, Warp can enter a runaway background Git indexing and syntax parsing state that results in unbounded memory growth, sustained disk I/O, and an inability to exit the application cleanly.

In this incident, Warp reached approximately 30 GB of committed memory and performed roughly 22 GB of disk writes. All agents were stopped successfully, but the Warp process itself could not be closed via normal means (Alt+F4 or menu quit) and required force termination.

WinDbg analysis of a full user-mode process dump shows Warp repeatedly executing the following code paths:

• warp!git_index_checksum
• warp!tree_sitter_rust
• warp!onig_get_string_by_callout_args

This strongly indicates a runaway Git repository indexing and syntax parsing loop (Tree-sitter + Oniguruma regex), rather than an AI model–related issue.

To reproduce

Exact reproduction is not yet deterministic, but the issue appears correlated with opening or working in a Git repository that triggers background indexing and code intelligence.

Observed steps:

1. Open Warp on Windows
2. Open a workspace or directory containing a Git repository
3. Allow background Git indexing and syntax parsing to begin
4. Continue normal usage or leave Warp idle
5. Within minutes (or after background indexing begins), observe rapidly increasing memory usage and sustained disk writes
6. Stop all Warp agents (succeeds)
7. Attempt to close Warp via menu or Alt+F4
8. Warp remains running and unresponsive; force termination is required

Once the runaway state begins, memory and disk usage continue increasing until the process is forcibly killed.

Expected behavior

• Background Git indexing and syntax parsing should complete, terminate, or throttle correctly without runaway loops.
• Warp should release memory once background tasks complete or are cancelled.
• Warp should exit cleanly, even if background workers encounter errors or cannot quiesce immediately.
• Disk I/O should remain bounded during idle or steady-state operation.

Screenshots, videos, and logs

Attached:

• WinDbg_Analyze_Output.txt — output from WinDbg !analyze -v
• WinDbg_Thread_Stacks_Output.txt — output from WinDbg ~* kb (all thread stacks)

Observed during investigation (screenshots no longer available):

• Task Manager showed approximately 30 GB of committed memory for one Warp.exe process
• Sustained disk I/O totaling approximately 22 GB of writes
• Two Warp.exe PIDs present (expected for an Electron-based application)
• All Warp agents were successfully stopped, but the Warp process itself could not exit cleanly

Logs:

• The Warp logs directory was inspected; it did not reflect the observed volume of disk writes, suggesting internal buffering, temporary files, or non-standard logging paths.

Notable stack pattern (from dump analysis)

warp!git_index_checksum
warp!git_index_checksum
warp!git_index_checksum
warp!onig_get_string_by_callout_args
warp!tree_sitter_rust
KERNELBASE!WaitOnAddress
ntdll!NtWaitForAlertByThreadId

The thread stacks show one or more threads actively looping in Git indexing and syntax parsing code paths, while many background executor threads were blocked waiting on shared state. The UI thread was idle in the Windows message loop.

Note: A full user-mode process dump (~30 GB) was captured and analyzed locally using WinDbg.
Due to its size and sensitivity, the dump file is not attached, but it can be provided via Dropbox Transfer or another secure channel upon request.

WinDbg_Analyze_Output.txt
WinDbg_Thread_Stacks_Output.txt

Operating system (OS)

Windows

Operating system and version

Microsoft Windows 11 Pro for Workstations (10.0.26200 Build 26200)

Shell Version

PowerShell 7.5.4

Current Warp version

v0.2026.01.21.08.14.stable_04

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

1/30/2026

Additional context

• This issue is not related to AI model responses (distinct from [BUG] Severe memory leak: Warp consumes 6-9GB memory on single model response #8544); no AI interactions were occurring when the runaway behavior began.
• Analysis of a full user-mode process dump strongly suggests a runaway background executor involved in Git repository indexing and syntax parsing (Tree-sitter / Oniguruma), rather than a UI, shell, or AI-related issue.
• The behavior appears related in class to memory growth during Git change analysis (e.g. Specific memory leak with large files in git changes #8413), but with additional and more severe symptoms:
  • Sustained, unbounded disk I/O growth
  • Memory consumption increasing to tens of gigabytes
  • Warp unable to exit cleanly even after all agents are stopped
• No wait-chain deadlock was detected. At the time of capture, the process was actively running, with multiple background threads blocked waiting on shared state while one or more threads continued looping in indexing/parsing code paths.

Observed impact:

• Memory and disk usage began increasing shortly after background indexing activity started and continued until the process was forcibly terminated.
• Because background workers did not quiesce, Warp could not shut down cleanly, leaving the main process running indefinitely.

Impact / Severity

High severity. When this condition is triggered, Warp becomes effectively unusable:

• Memory usage grows without bound, exhausting system resources
• Sustained disk writes significantly degrade overall system performance
• Warp cannot shut down cleanly and must be force terminated
• Active sessions risk data or state loss

This blocks normal daily use of Warp until the process is forcibly killed.

Hypothesis

A background executor responsible for Git repository indexing and syntax parsing enters a non-terminating loop, repeatedly reprocessing repository state. This causes continuous memory allocation and disk writes while preventing background workers from quiescing during shutdown, leaving the main Warp process unable to exit cleanly.

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None