Updating warp lost all recent sessions

[TimeScience]

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 Mac, I clicked on "update warp" as I've done many other times and it updated but lost all my open tabs. MY sessions history only seems to start over a week ago so all recent sessions have disappeared.
I asked the agent to debug it and it dug around in the sql db but then ran out of credits after telling me "... today’s commands are all recorded with session_id = NULL" so that's as far as I got.

The version just installed v0.2026.05.18.05.32.stable_02

To reproduce

On Mac, let warp update itself to v0.2026.05.18.05.32.stable_02
When it loads observe all your recent sessions have been lost.
Ask agent to debug itself
Agent runs out of credits
Curse at agent and warp
File bug report

Expected behavior

Every other "update warp" has worked fine and all previous sessions reloaded

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

Mac OS 26.3 (25D125)

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.05.18.05.32.stable_02

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

previous version (which is likely next most recent version since I always update when asked to)

Additional context

No response

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

[oz-for-oss]

@TimeScience

Here's what I found while triaging this issue:

This appears to involve Warp's local session/tab restoration data rather than shell history alone. Please avoid attaching the local session database publicly, since it may contain private command and session content; redacted logs are safer to share in the issue thread.

I have a few follow-up questions before I can narrow this down:

1. Can you attach redacted Warp logs from the update and first restart where the tabs disappeared?
2. After fully quitting Warp and reopening it again, are the missing tabs and recent session history still absent?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that macOS update to v0.2026.05.18.05.32.stable_02 reportedly lost restored tabs and recent session history, likely involving local session/tab persistence but needing logs or persistence-state evidence to isolate..

Triage summary

This looks like a macOS regression around session/tab restoration after updating to v0.2026.05.18.05.32.stable_02. The report has enough detail to route to the window/tab persistence area, but it still needs first-launch/update logs or persistence-state evidence before maintainers can tell whether the saved tab tree was not read, was rejected during restore, or was overwritten after startup.

Reproducibility

Medium. The report includes OS, Warp version, shell, regression timing, and a clear update-triggered symptom, but this is currently a single data-loss report without logs, screenshots, database snapshots, or a second confirming report.

Likely area

The relevant code path is local SQLite-backed app-state restoration:

• app/src/workspace/global_actions.rs sends ModelEvent::Snapshot from the save-app path.
• app/src/persistence/sqlite.rs deletes and rewrites saved windows/tabs/panes in save_app_state, and later reads persisted windows/tabs/block lists in read_sqlite_data.
• app/src/workspace/view.rs rebuilds a restored workspace from the saved window snapshot.
• app/src/pane_group/mod.rs restores pane trees from snapshots and falls back to a new terminal if restore fails.
• app/src/terminal/history.rs and crates/persistence/src/schema.rs are relevant for the reported session_id = NULL command-history observation. That observation is diagnostic, but not sufficient by itself to prove why the tabs/session history disappeared because command rows explicitly allow nullable session_id.

Duplicate check

I checked all open issues plus recently closed issues. Related issues exist, including #9109 for tab restoration after close/reopen and #3910 for restored tabs losing working paths after reboot, but fewer than two candidates match this exact update-lost-tabs/recent-sessions symptom strongly enough to label this as a duplicate.

Question reasoning

1. Can you attach redacted Warp logs from the update and first restart where the tabs disappeared? — Logs can show whether SQLite app-state restore failed, whether a migration/update error occurred, or whether a fallback/new-session path overwrote the saved tab state.
2. After fully quitting Warp and reopening it again, are the missing tabs and recent session history still absent? — This distinguishes a transient first-launch restore/display failure from persisted app-state data that has already been overwritten or deleted.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[TimeScience]

UPDATE: I was able to use claude code to recover my sessions.

Below is the summary of what it tried and what worked. Not so much about what actually caused the problem, but hopefully this is helpful for anyone facing the same problem.

Bug: Auto-update destroys session state (all tabs lost)

Environment

• macOS (Darwin)
• Warp Stable channel
• Session restore enabled (default setting, not overridden in ~/.warp/settings.toml)
• ~19 tabs open across one window prior to update

What happened

Warp auto-updated and restarted. On relaunch, session restore returned 1 window with 2 panes (a default terminal at ~ and a Settings pane) instead of the ~19 project-specific tabs that were open before the update.

Root cause analysis

Warp stores session layout in a SQLite DB (WAL mode) at:

~/Library/Group Containers/2BBY89MBSN.dev.warp/Library/Application Support/dev.warp.Warp-Stable/warp.sqlite

The session layout is spread across five tables: windows, tabs, pane_nodes, pane_leaves, and terminal_panes. After the update restart, these tables contained only 2 rows (the minimal default state), meaning the previous session layout was overwritten rather than restored.

Key observations:

• DB integrity was fine — PRAGMA integrity_check passed, no FK violations
• No new schema migration ran during the update (last migration timestamp: 2026-05-01)
• Command history survived — the blocks table was intact (512 blocks across 40 distinct pane_leaf_uuid values), with pwd fields still referencing the historical working directories
• Session restore was enabled — verified in settings; no explicit override in ~/.warp/settings.toml

This suggests the update triggered a restart that wrote a fresh minimal session state into the layout tables before (or instead of) reading the prior state for restoration. The blocks table was not affected because it is append-only history, not session layout.

Recovery

Attempt 1: Direct DB modification (failed)

1. Backed up the DB + WAL + SHM files
2. Quit Warp
3. Inserted new rows into windows, tabs, pane_nodes, pane_leaves, and terminal_panes for the 19 directories identified from SELECT DISTINCT pwd FROM blocks
4. Relaunched Warp

Result: Warp overwrote the injected rows on startup — the DB was clobbered within ~1 minute. Warp appears to rebuild session state on launch rather than trusting pre-existing rows, or the WAL was not properly checkpointed before Warp read the main DB file.

Attempt 2: open -a Warp (succeeded)

Extracted working directories from the surviving command history, then opened each as a new tab:

1. Extract project directories from command history
   WARP_DB="$HOME/Library/Group Containers/2BBY89MBSN.dev.warp/Library/Application Support/dev.warp.Warp-Stable/warp.sqlite"
   sqlite3 "$WARP_DB" "SELECT DISTINCT pwd FROM blocks WHERE pwd IS NOT NULL AND pwd != '' ORDER BY pwd;"

2. Open each as a new Warp tab
   open -a Warp /path/to/project1
   open -a Warp /path/to/project2
   ... etc

This successfully restored 18 of 19 tabs (one directory had been deleted from disk since the original session).

Claude suggested fix :)
The session layout tables should be persisted before the update restart begins — either by snapshotting them to a separate recovery table/file, or by ensuring the existing DB is read before being overwritten on the post-update launch. The blocks table proves the DB itself survives the update; only the layout tables are lost.

[oz-for-oss]

@TimeScience

Here's what I found while triaging this issue:

Thanks for the detailed recovery notes. The fact that command history survived while the open tabs did not points more toward the saved window/tab layout being overwritten during the update/relaunch path than toward full database corruption. Your open -a Warp <directory> recovery path is a reasonable workaround when command history still contains the old project directories.

I have a few follow-up questions before I can narrow this down:

1. Can you attach redacted Warp logs covering the update and first relaunch into v0.2026.05.18.05.32.stable_02?
2. Was the Settings pane already open before you clicked update, or did it appear only after Warp relaunched?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that macOS Stable auto-update appears to have relaunched with a freshly persisted minimal tab/session layout, leaving command history intact but replacing the recent open-tab layout..

Triage summary

• Observed symptom: On macOS Stable, updating to v0.2026.05.18.05.32.stable_02 relaunched Warp with only a minimal window layout instead of the reporter's ~19 open tabs. The reporter later recovered most project directories from surviving command history.
• Routing: This is best treated as a macOS window/tab/session restoration bug. The agent credit exhaustion is incidental to the reporter's debugging attempt, not the primary product area.
• Reproducibility: Medium. The report has a concrete update version and strong post-failure observations, but it is still a single update incident without logs or a repeatable fresh-profile repro.
• Likely code area: Session layout is loaded from SQLite during startup in app/src/persistence/sqlite.rs and restored via app/src/root_view.rs / app/src/workspace/view.rs. Layout snapshots are produced from live windows in app/src/app_state.rs and persisted by workspace:save_app in app/src/workspace/global_actions.rs. The macOS update/relaunch path runs through app/src/autoupdate/mod.rs, app/src/autoupdate/mac.rs, and shutdown callbacks in app/src/lib.rs.
• Current hypothesis: The previous layout may have been replaced by a post-update minimal snapshot during or after relaunch. This fits the report that command history survived while the open window/tab layout did not, because those are persisted through different code paths.

Follow-up needed

The remaining ambiguity is why the minimal layout became the authoritative snapshot for this user. Logs from the update/relaunch window should help distinguish a restore failure, a startup fallback, or a later save of an already-minimal workspace.

Question reasoning

1. Can you attach redacted Warp logs covering the update and first relaunch into v0.2026.05.18.05.32.stable_02? — Logs are the most direct way to distinguish a failed session restore, a startup fallback to a default window, or a later save that overwrote the old layout.
2. Was the Settings pane already open before you clicked update, or did it appear only after Warp relaunched? — The post-update state included a Settings pane; knowing whether it was part of the pre-update layout helps determine whether Warp restored an older/minimal snapshot or created a new minimal layout after the update.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[mfyameen]

Seconding this problem
occurs inconsistently - not on every update, but most updates. And it has been an issue for 6 months at least