Making terminal threads persistent / adding support for resurrection

[PrayagS]

What are you proposing?

After a while, the terminal thread's state is reset and the default shell is opened.

I'm not sure of the exact approach here but all major harnesses support resuming a session using a session identifier. If upon waking up an old thread, zed can use the corresponding harness' resume command, the experience will be much better.

Similar to how https://github.com/timvw/tmux-assistant-resurrect works.

How this information (the harness and the session identifier) is passed over to zed is up for debate. It could be something that the harness has to do, similar to how notifications work currently (terminal bell support is expected from the harness).

[PrayagS]

To expand on this, this should also be doable on the back of let's say tmux. But for that, #57427 needs to be implemented.

Because then similar to normal terminal panels, I can configure a terminal thread to open in a new/existing tmux session.

[PrayagS]

❯ env | rg zed_
ZED_ENVIRONMENT=worktree-shell
ZED_TERM=true

Envars can be helpful for sharing information between zed and the shell. If zed is exporting a particular identifier, I can use that to maintain a corresponding tmux session.

[macraig]

Hi @PrayagS , thanks for the feedback. This is already on our ToDo list. We just need a bit of time to figure out the best way to implement it in terminals. We'll keep this thread updated!

[Jiashu-Hu]

Possible implementation / reference design

I think cmux's implementation is a very useful reference for this feature.

From what I understand, cmux does not try to checkpoint arbitrary live terminal process memory. Instead, it separates normal terminal/session restoration from AI agent session restoration:

1. Save the app/workspace/pane layout, working directory, and terminal context.

2. Use agent-specific hooks/wrappers to capture the native agent session ID.

3. Store a mapping between the terminal surface and the agent session metadata, such as:

   • agent kind: Claude Code, Codex, OpenCode, Amp, Pi, etc.
   • native session ID
   • working directory
   • original launch command
   • sanitized environment / launch arguments
   • workspace or surface identifier

4. On app restore, rebuild the window/workspace/pane layout first.

5. If automatic agent resume is enabled, run the corresponding native resume command for that agent.

For example:

Claude Code: claude --resume <session-id>
Codex:       codex resume <session-id>
OpenCode:    opencode --session <session-id>
Amp:         amp threads continue <session-id>
Pi:          pi --session <session-id>

A similar model could work well for Zed Terminal Agent Threads.

Zed could persist a small metadata record for each Terminal Agent Thread, for example:

terminal_thread_id
project_id / worktree_id
cwd
agent_kind
agent_session_id
launch_command
sanitized_env
last_updated_at

Then, when Zed restarts, updates, or recovers from a crash, it could restore the Terminal Agent Thread entry in the Threads Sidebar and relaunch the correct agent using the agent's native resume command.

This would be much more reliable than only restoring the terminal scrollback or reopening a default shell, because AI coding agents already have their own session model. Zed only needs to preserve the mapping between the Terminal Thread and the agent's native session ID.

It may also be useful to provide settings such as:

{
  "terminal_agent_threads": {
    "auto_resume": true,
    "auto_resume_agents": ["claude", "codex", "opencode", "amp", "pi"]
  }
}

This would let users choose whether Zed should automatically resume agent sessions after reopening, while still allowing Zed to restore the layout without executing agent resume commands if the user disables auto-resume.

I think this cmux-style approach would fit Terminal Agent Threads very well, because it treats AI terminal sessions differently from ordinary shell processes. For normal shell commands, best-effort terminal restore is enough. But for AI agents, preserving the agent session ID and calling the native resume command is the key part.

[Jameson-Crate]

This would be super helpful, #58693 is really good, but only addresses half of the problem imo. This restarting behavior is also really important.

[Jiashu-Hu]

Oh that's great, I've leave a comment on that PR this actually did a great foundation

[silouanwright]

+1 to the cmux-style approach here. I think the important distinction is that “restore the terminal” and “resume the agent conversation” should be treated as separate layers.

For ordinary shells, best-effort restoration of cwd/scrollback/layout is probably enough. But for Terminal Agent Threads, the durable object is usually the agent’s own native session ID, not the live terminal process. So the robust path seems to be:

1. Zed restores the workspace/thread/sidebar surface first.
2. Zed preserves a small mapping from Terminal Thread → agent metadata.
3. The agent (or a small wrapper/hook) records its native session ID.
4. On restore, Zed offers to run the agent’s native resume command.

For example:

Pi:     pi --session <id>
Claude: claude --resume <id>
Codex:  codex resume <id>

The pieces I’d especially want exposed are stable identifiers such as:

ZED_TERMINAL_THREAD_ID
ZED_WORKSPACE_ID
ZED_WORKTREE_ID

Then agent CLIs or small integration hooks could reliably bind their native session IDs to the Zed Terminal Thread that owns them.

I’d also suggest making auto-resume user-controlled and staged, not just “restart everything.” In large multi-agent workspaces, bulk-resuming every agent after a crash/update could recreate the same resource pressure that caused the restart. A good UX might be:

• restore thread entries/layout immediately
• show which agent sessions are resumable
• resume current thread/workspace on demand
• optionally enable trusted auto-resume for selected agents

Security-wise, Zed should probably avoid storing/rerunning arbitrary shell strings unless they match trusted/allowlisted resume commands, with sensitive env stripped.

Overall I think this is exactly the right model: don’t try to checkpoint arbitrary terminal process state; persist the Terminal Thread ↔ native agent session mapping and let each agent resume itself.

[bestin-fw]

really appreciate all the work that is being put into making the editor a delight to use. The send to terminal thread came really handy in day to day. This is another missing piece that would really improve the quality of life. hope it arrives soon.

[zxnie]

Love this proposal, primary reason I'm still using herdr.

[rbstp]

Let me know if you have any feedback regarding the last change (see last comment) #58693 (comment)

[gopigraphy]

been waiting for this feature for so long! please make it happen

p.s. love zed

[johnnybq]

I have a working AgentDeck/tmux proof of concept for this: sessions survive Zed and macOS restarts, selecting a restored Terminal Thread reattaches to the existing tmux session, and a small bridge tracks session creation, renames, and removal.

The remaining gap is live discovery. Stock Zed only sees externally added Terminal Thread metadata after an app reload. My prototype writes namespaced rows to sidebar_terminal_threads, which proves the UX, but I do not think private SQLite or WAL watching should become the integration contract.

Before preparing a PR, which first-class ingress would best fit the direction of Terminal Threads: typed local CLI IPC for idempotent register/update/unregister, a watched provider manifest, or stable Zed thread/workspace IDs plus hooks? I would keep TerminalThreadMetadataStore authoritative so persistence and Sidebar notifications remain native, with no polling or AgentDeck-specific code.

If you can point me to the preferred seam, I would be happy to implement the smallest version with focused tests and a tmux demo.

Disclosure: I used AI to verify the current code paths and tighten this note; I reviewed the proposal and tested the proof of concept locally.