All retained agent threads are re-homed to the active project on worktree events
What happens
Every agent thread that has been opened in the session (i.e. is in retained_threads, plus the active one) gets stamped with the active project's worktree paths whenever a worktree event fires. Threads from other projects — including remote/SSH ones — are silently re-homed into the active project, and the sidebar regroups them under it.
Reproduction
- Open agent threads from project A (they stay retained).
- Switch to project B and trigger a worktree update there (we saw it on worktree add/open; any event that reaches
update_thread_work_dirs). - The project-A threads now carry project B's folder paths and appear under B's sidebar group; A's group loses them.
We hit this during a long session: 36 threads belonging to SSH project groups (~/Company/KK-Backend|KK-Frontend|infra, ~/Company/revenue_iro, …) were all re-homed to /etc/nixos at once. Thread content was intact (threads.db untouched), but the metadata store (db.sqlite → sidebar_threads) had been rewritten, and there is no in-product way to move threads back.
Cause
AgentPanel::update_thread_work_dirs (crates/agent_ui/src/agent_panel.rs) calls ThreadMetadataStore::update_worktree_paths(&thread_ids, new_worktree_paths, cx) for all retained threads plus the active one, with the current project's WorktreePaths; crates/agent_ui/src/thread_metadata_store.rs then saves those paths onto each thread, with no check that the thread already belongs to that project.
Proposed fix
Only re-home a thread whose stored folder paths are a subset of the new worktree set (the archived check above it stays). I have this change in my fork (compiles and runs; the affected function is unchanged on main) and will open a PR.
Source: zed-industries/zed