Warp hangs on "Starting Windows PowerShell..." after update due to unbounded blocks table growth

[649993558-alt]

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

After updating Warp to a new version, Warp hangs indefinitely on "Starting Windows PowerShell..." and becomes completely unresponsive.

Root cause identified: The blocks table in warp.sqlite (located at %LOCALAPPDATA%\warp\Warp\data\warp.sqlite) grows without any size limit. When Warp restarts after an update, it attempts to synchronously load ALL rows from the blocks table to restore terminal sessions. If the user has been using Warp for days/weeks before the update, the blocks table can accumulate tens of thousands of rows (database size 200MB-1GB+), causing the restore process to hang.

Workaround: Manually running DELETE FROM blocks on the SQLite database and then restarting Warp resolves the issue immediately. All windows, tabs, conversations, and command history are preserved — only the terminal output display is cleared.

To reproduce

1. Use Warp normally for several days/weeks with multiple tabs open, running many commands
2. Check the database: %LOCALAPPDATA%\warp\Warp\data\warp.sqlite — the blocks table will have thousands of rows, database size > 200MB
3. When Warp prompts for an update, allow it to update and restart
4. Warp hangs on "Starting Windows PowerShell..." — the UI is unresponsive, CPU usage spikes
5. Force-kill Warp, run: sqlite3 warp.sqlite "DELETE FROM blocks; VACUUM;"
6. Restart Warp — it launches normally within seconds

Expected behavior

Warp should start normally after an update, regardless of how long it has been used or how many commands have been executed.

Specifically:

• The blocks table should have a retention policy (e.g., keep only last N blocks or last X MB)
• Session restore should be asynchronous/lazy-loaded, not block the startup path
• If restore takes longer than a few seconds, Warp should show the terminal anyway and load history in the background
• The update process should clean up or compact old session data before restarting

Screenshots, videos, and logs

Database analysis from an affected instance:

• Database size: ~400 MB
• blocks table: 15,000+ rows (this is the cause)
• windows / tabs / pane_nodes: normal row counts
• After DELETE FROM blocks + VACUUM: database shrunk to ~30 MB, Warp starts in <3 seconds

No crash log is generated because Warp doesn't crash — it hangs indefinitely during session restore.

Operating system (OS)

Windows

Operating system and version

Windows 11 24H2

Shell Version

PowerShell 5.1 / pwsh 7.x

Current Warp version

v0.2026.03.04.08.20.stable_02

Regression

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

Recent working Warp date

No response

Additional context

This is a design-level performance bug, not a one-time crash. The issue affects any long-term Windows user who doesn't regularly restart Warp.

Technical details:

• The blocks table stores terminal output buffer snapshots for session restore
• There is no automatic cleanup, TTL, or size limit on this table
• On startup, Warp loads the entire table synchronously, blocking the UI thread
• The more commands a user runs before an update, the worse the hang becomes

Suggested fixes (any one would prevent the hang):

1. Add a retention policy to blocks (e.g., keep last 1000 rows or last 50MB)
2. Load blocks asynchronously after UI is rendered
3. Add a startup timeout — if restore takes >5s, skip and show empty terminal
4. Run DELETE FROM blocks WHERE created_at < X during the update process

Community impact: I've built an open-source fix tool for this: [link to your repo if you want to share]

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

[DebutiIR]

stuck on "starting windows powershelll ...." as well

[Radheshg04]

any updates on this?

[oz-by-warp]

We need a bit more information before we can continue triaging this issue.

If you're still hitting this, could you try reproducing it on the latest version of Warp and share logs along with a screenshot or short video if possible?

If there's no activity after 3 business days, we'll close this out to help keep the tracker tidy.

---

This is part of an automated backlog review and may be inaccurate. If you believe this assessment is wrong, please let us know.