Enable unsaved buffer persistence for worktree-less windows

[luukverhoeven]

Closes #15098.

Previously, unsaved buffers in empty windows (no project open) or single file editing sessions were not persisted across restarts. This change enables the hot-exit functionality for these scenarios by:

• Always serializing dirty buffers regardless of worktree presence
• Including empty workspaces in session serialization
• Removing the DetachFromSession behavior for local empty windows

Release Notes:

• Added support for restoring unsaved buffers in empty windows and single-file editing sessions
  (#15098)

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @luukverhoeven on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[nathansobo]

I pushed a fix for the dead code issue.

You'll need to sign the CLA at https://zed.dev/cla and then comment @cla-bot check.

---

Regarding the implementation itself, I have a question about how empty workspaces are identified.

Currently, workspaces are looked up by their paths:

WHERE paths IS ? AND remote_connection_id IS ?

With this change, empty workspaces would serialize with paths = "". But this creates a problem:

• If I open two empty windows, each with different unsaved buffers, they both have the same "key" (empty paths, no remote connection)
• When saving, the query DELETE FROM workspaces WHERE workspace_id != ?1 AND paths IS ?2 would delete the other empty workspace
• When restoring via workspace_for_roots(&[]), we'd just get whichever one comes back first (LIMIT 1)

So I think we need to figure out the intended behavior:

1. Should there only ever be one empty workspace that accumulates all unsaved buffers from all empty windows?
2. Or should multiple empty windows each persist their own state? If so, we'd need a different identification mechanism (maybe a UUID stored with the window?)

What do you think?

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[echuber2]

Is PR #46557 trying to solve the same problem?

[SomeoneToIgnore]

This seems very stale, at least no one had thought on it since the question in 2025 above, hence I'll close.