Archive terminals on close instead of killing them (keep the session, restore it later)

[isaachorowitz]

1. Why this matters

Problem. Closing a terminal tab in Zed kills the process running inside it. If that terminal holds a long-lived session (a dev server, a language REPL, an SSH connection, a tmux session, or an AI coding agent such as Claude Code / Codex), an accidental close destroys the session with no way to get it back. The only current mitigation people ask for is a confirmation dialog, which nags on every close and still throws the session away if you dismiss it wrong.

Evidence (existing demand in this repo):

• confirmation on closing terminal that has running process #20051 "confirmation on closing terminal that has running process" — open, 33 👍, and a Zed team member is engaged in the thread. A contributor's own comment states the core problem plainly: "The garbage can button kills the terminal instead of closing it."
• Warn before closing when the current project still has running terminal processes #57329 "Warn before closing when the current project still has running terminal processes" — open.
• Child processes not terminated when integrated terminal closes #47412 "Child processes not terminated when integrated terminal closes" — open; shows the close/kill lifecycle is already a pain point.
• Discussion Making terminal threads persistent / adding support for resurrection #57428 "Making terminal threads persistent / adding support for resurrection" — existing appetite for keeping terminal sessions alive.

Prior art:

• VS Code: terminal.integrated.confirmOnExit: "hasChildProcesses" guards against losing a terminal with a running process; VS Code also persists/reconnects terminal sessions across reloads.
• tmux / screen: detach and reattach keep a session alive independently of the frontend.
• Browsers: "reopen closed tab" (Cmd/Ctrl+Shift+T) is the universal muscle-memory answer to "I closed that by mistake."

Framing. Every request so far asks for a confirmation dialog. Archiving is a strictly stronger answer to the same 33-👍 pain: don't nag, and don't lose it. Closing hides the terminal and keeps its session alive; you restore it when you want it back, or force-delete it when you actually mean to kill it.

2. What is it

Feature: an opt-in "archive on close" mode for terminals.

Purpose: when enabled, closing a terminal archives it (hidden, but its PTY and child process keep running) instead of killing it. Archived terminals appear in a collapsible "Archived" section in the terminal panel. Restoring one drops you straight back into the live session; a separate "Force delete" truly kills it (the current behavior). Archived entries are labeled by what is running in them (this composes with the separate terminal.tab_title_from_program change in #61188, so a shelf of archived claude / codex / ssh prod sessions is legible at a glance).

Mechanism (grounded in the current code):
Zed's terminal process runs on a detached alacritty EventLoop IO thread that owns the PTY and child (crates/terminal/src/alacritty.rs). The process is killed only when the Terminal GPUI entity is dropped: its Drop impl (crates/terminal/src/terminal.rs) sends the PTY shutdown and then SIGTERM/SIGKILL. On the normal close path (Pane::_remove_item in crates/workspace/src/pane.rs), the last strong Entity<TerminalView> handle is dropped, which cascades to dropping the Terminal and killing the child.

So "keep alive" requires no change to the kill logic at all — it is achieved by retaining the strong Entity<TerminalView> in a panel-owned archived collection instead of dropping it on close. Restore = re-insert that handle into the pane via Pane::add_item. Force-delete = drop it (or call the existing explicit kill), which runs Terminal::drop exactly as today. This keeps the change surgical and localized to terminal_panel plus a setting.

Decision to confirm with the team: whether "close archives" should be opt-in behind a setting (default = today's kill behavior, no surprise for existing users) or become the default with force-delete as the escape hatch. This proposal assumes opt-in, default off.

3. What else does this affect

• Actions & keybindings. New actions: restore-archived-terminal and force-delete-archived-terminal; "archive" is implicit in the existing close gesture when the mode is on. No new default keybinding is strictly required (close stays the close gesture); force-delete can be a menu item / affordance in the Archived list. Need to confirm no conflict with existing terminal actions.
• Settings. One new per-user setting (e.g. terminal.close_action: "kill" | "archive", default "kill"), added to the Settings UI. Not per-project.
• Themes & styling. The Archived section and its restore / force-delete affordances must read correctly in light and dark and reuse existing panel/list/icon tokens (no new semantic tokens expected).
• Vim mode. No special interaction expected.
• Remote development. For remote projects the child runs on the host; retaining the entity keeps the channel open. This needs explicit testing and may be scoped out of v1.
• Persistence across restarts. Honest boundary: a live OS process cannot survive a full app quit without a tmux-style daemon, which is out of scope here. v1 target: archived terminals persist like normal terminals do today (working directory + title) and relaunch on restart; live-session survival applies only within a running Zed session. tmux-style resurrection (Discussion Making terminal threads persistent / adding support for resurrection #57428) is a natural follow-up, not part of v1.
• Accessibility. The Archived list must be keyboard-navigable, with restore/force-delete reachable and clear focus states.
• Platform differences. The mechanism (don't drop the entity) is platform-agnostic, but the PTY/child lifecycle differs on Windows (ConPTY); needs testing on all three platforms.
• Performance & resources. Archived terminals keep their PTY, IO thread, and scrollback in memory, and hold file descriptors. A large archive shelf therefore has a real memory/fd cost — relevant given Zed's prior fd-exhaustion history (Zed leaks thousands of file descriptors (mostly /proc/<pid>/* handles), exhausting system-wide fd limit and crashing the desktop compositor #60269) and the child-process concerns in Child processes not terminated when integrated terminal closes #47412. Proposed mitigations: surface the archived count, and consider a cap or an eviction/age-out policy. This is an explicit open question below.
• Security / Workspace Trust. "Hidden but alive" processes must never be silently hidden: the Archived list (and a count badge) must make it obvious that archived sessions are still running, and force-delete must reliably terminate them via the existing Drop/kill path.

4. Open questions for maintainers

1. Opt-in setting (default off) vs. making archive-on-close the default with force-delete as the escape?
2. UI home for archived terminals: a collapsible section in the terminal panel (this proposal) vs. a searchable picker?
3. v1 scope for remote projects and for cross-restart behavior?
4. Resource policy: hard cap, age-out, or unlimited-with-a-visible-count?
5. Naming of the setting and the restore / force-delete actions.

I have the terminal lifecycle, panel, and persistence paths mapped and am happy to bring a working prototype / PR quickly once there's agreement on direction (per the contributing guide's "open a PR early once we agree on the change").