Dragging convo to tabs pane deletes the convo history

[rpg777]

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

*From my session rn with Warp, where I am reying to get back ~$100 worrth of token actions and scripts and countless hours of my own time. *

...
The script refuses to run if it detects Warp still running, takes its own timestamped backup to ~/warp_db_prerestore_/ before touching anything, checkpoints the WAL, re-inserts the conversation row plus all 243 prompts with INSERT OR IGNORE and fresh row ids, then verifies counts and runs integrity_check. It prints the rollback path at the end.

Expected outcome: the conversation reappears in your list. Whether the full agent text comes back depends on whether the server-side copy survived the delete — if it didn't, you'll get the entry plus your prompts, and the markdown transcript covers your side regardless.

Two things to avoid until Warp ships a fix:
• Don't drag panes onto the tab bar. That's what deleted the conversation, and it was my suggestion that led you there. To get conversations into separate tabs, press ⌘T first, then /conversations in the new tab.
• The fork 56d0b52e (244 prompts) is the safer copy of that work — it holds 241 of the 243 prompts.

Worth filing with Warp support, since you have clean evidence: PaneHeaderDropped { drop_location: TabBar(...) } immediately followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found, on v0.2026.07.29.09.05.stable_02, with a hard conversation delete as the result and no user delete action in the log.

To reproduce

Worth filing with Warp support, since you have clean evidence: PaneHeaderDropped { drop_location: TabBar(...) } immediately followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found, on v0.2026.07.29.09.05.stable_02, with a hard conversation delete as the result and no user delete action in the log.

Expected behavior

No response

Screenshots, videos, and logs

Worth filing with Warp support, since you have clean evidence: PaneHeaderDropped { drop_location: TabBar(...) } immediately followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found, on v0.2026.07.29.09.05.stable_02, with a hard conversation delete as the result and no user delete action in the log.

Operating system (OS)

macOS

Operating system and version

15.7.7

Shell Version

No response

Current Warp version

v0.2026.07.29.09.05.stable_02

Regression

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

Recent working Warp date

No response

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

No response

[oz-for-oss]

@rpg777

Here's what I found while triaging this issue:

Thanks for the detailed logs. This looks like a pane/tab drag bug rather than a user-initiated conversation delete; avoiding pane-header drags to the tab bar is the safest workaround for now.

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

1. Can you attach a short screen recording showing the exact drag path and what happens to the conversation list afterward?
2. After the drag, does the conversation disappear immediately, only after restarting Warp, or only after trying to reopen the moved tab?

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 dragging an agent conversation/pane to the tab bar on macOS appears to route through pane move/close handling and can orphan or remove conversation history without an explicit delete action..

Triage summary

The report describes a macOS Stable regression where dragging an agent conversation/pane to the tab bar appears to remove the conversation history. The supplied PaneHeaderDropped { drop_location: TabBar(...) } log followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found aligns with the pane header drag/drop path rather than the explicit conversation delete action.

Reproducibility

Medium. The report provides OS, Warp build, a concrete drag/drop action, and matching logs, but it does not yet include a screen recording or exact source/target surface for the drag.

Likely root cause

Pane-header drops route through PaneHeaderDropped -> PaneViewEvent::DroppedOnTabBar -> Workspace's DroppedOnTabBar handling, which calls PaneGroup::remove_pane_for_move. That function focuses/removes the source pane and can emit Exited when the pane is the last visible pane. For agent/child-agent panes, the generic drag-to-tab-bar path appears to bypass the dedicated child-agent split-off path (OpenChildAgentInNewTab / take_child_agent_pane_for_split_off) that preserves child-agent ownership/origin metadata, so a drag can be treated more like a close/move cleanup than a safe conversation re-host. The explicit deletion path (conversation_utils::delete_conversation) is separate and normally requires the delete confirmation dialog, so the reported no-user-delete-action behavior is plausible if the pane move path orphaned or cleaned up conversation state.

Relevant files

• app/src/pane_group/pane/view/header/mod.rs
• app/src/pane_group/pane/view/mod.rs
• app/src/pane_group/mod.rs
• app/src/workspace/view.rs
• app/src/pane_group/pane/terminal_pane.rs
• app/src/ai/conversation_utils.rs
• app/src/ai/blocklist/history_model.rs

Duplicate check

Checked all open issues and recently closed issues. Related drag/tab issues (#14346, #14387) cover different tab-drag corruption/performance symptoms, so this should not be marked duplicate.

Question reasoning

1. Can you attach a short screen recording showing the exact drag path and what happens to the conversation list afterward? — The issue is visual/interaction-based, and a recording would confirm the source pane, drop target, and whether the list entry disappears immediately.
2. After the drag, does the conversation disappear immediately, only after restarting Warp, or only after trying to reopen the moved tab? — This distinguishes an in-memory pane ownership/orphaning bug from persisted conversation deletion or session-restoration cleanup.

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

Powered by Oz

[warp-agent-staging]

Oz couldn't complete this task because required inputs, permissions, or resources were invalid or unavailable.

Error Details:
Environment setup failed: Failed to clone warpdotdev-demos/agent-eval-kit, warpdotdev/warp. Check your repository URLs and setup commands.

[rpg777]

Fuck off, I reported the thing, Warp wasted a lot of my time and money by RECOMMENDING I drag a convo to that tab pane and I got screwed as a result. You do your own goddamned work from here.

[oz-for-oss]

@rpg777

Here's what I found while triaging this issue:

The provided log sequence points to a pane-header drag/drop onto the tab bar followed by pane focus/close recovery, so this should be treated as a potential agent-conversation data-loss bug. Until this is verified, avoid dragging active agent conversation panes onto the tab bar; opening a new tab first and using the conversations UI is the safer workaround.

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

1. If you can reproduce this again, can you attach a short screen recording showing the exact drag source and drop target?
2. After restarting Warp, was the conversation absent from the conversations UI as well, or only missing from the tab/pane where it was being moved?

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 dragging an agent conversation pane onto the tab bar may route through generic pane-move cleanup and make the conversation disappear or be deleted..

Triage summary

This is a macOS Stable bug report about losing an agent conversation after dragging its pane/header onto the tab bar or tabs pane. The report includes a concrete Warp version (v0.2026.07.29.09.05.stable_02) and a useful log sequence: PaneHeaderDropped { drop_location: TabBar(...) } followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found, with no intentional user delete action reported.

Reproducibility

repro:medium: the log sequence maps to a real pane-header drag/drop path, and the report includes OS and app version. Confidence is not high because there is no minimal step-by-step reproduction, screenshot/video, or full redacted log showing whether the conversation was actually deleted from local/cloud persistence versus orphaned from the conversation list.

Likely root cause / code areas

The most likely path is manual pane-header drag/drop into the tab bar using the generic pane move flow rather than the child-agent-specific "open in new tab" flow:

• app/src/pane_group/pane/view/header/mod.rs emits PaneHeaderDropped with PaneDragDropLocation::TabBar.
• app/src/pane_group/pane/view/mod.rs, app/src/pane_group/mod.rs, and app/src/workspace/view.rs convert that into tab-bar drop handling and remove_pane_for_move / source-tab close behavior.
• app/src/pane_group/mod.rs contains the focus recovery path that reports [PaneGroup] Unable to locate a panel to activate after close when no prior visible pane can be selected.
• app/src/pane_group/pane/terminal_pane.rs, app/src/ai/blocklist/history_model.rs, and app/src/ai/conversation_utils.rs are relevant for conversation ownership, detach semantics, and actual local/cloud deletion.

Current code has specialized preservation/re-adoption logic for child-agent tabs opened via explicit child-agent actions (take_child_agent_pane_for_split_off, set_child_agent_origin, try_re_adopt_split_off_child_agent_tab), but a manual pane-header drag appears to go through the generic pane move path. That can plausibly leave agent conversation ownership/visibility inconsistent when the source tab has only that pane, though the hard-delete claim still needs confirmation from full logs or a local repro.

Duplicate check

I enumerated all open non-PR issues in warpdotdev/warp and found no exact matches for the reported PaneHeaderDropped / Unable to locate a panel log sequence. Several issues overlap on tab/pane drag or agent conversation terminology, but none share the same conversation-loss-on-pane-drag symptom, so this should not be marked duplicate.

Question reasoning

1. If you can reproduce this again, can you attach a short screen recording showing the exact drag source and drop target? — The code path differs depending on whether the user dragged a normal terminal pane, a visible child-agent pane, or a conversation-list/restored pane; visual evidence would disambiguate the route without asking for private conversation contents.
2. After restarting Warp, was the conversation absent from the conversations UI as well, or only missing from the tab/pane where it was being moved? — This distinguishes a true persistence/cloud deletion from a UI ownership/orphaning bug, which changes both severity and the likely fix path.

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

Powered by Oz

[rpg777]

I'm not going to recreate this, but I do have a conversation history with an agent from when this all happened and that was conclusive. How shall I share that with you?

I am already operating on the assumption that this is a bug, exactly as you describe, and the agent chat confirms this. Dragging a conversation to the tabs pane deletes the history. I'm currently terrified to do much of anything in the Warp AI now because I lost all my tabs form the UI with one simple drag drop that the agent even advised me to do. Then I had to burn thru tokens having the agent diagnose the issue and help restore the histories.

[oz-for-oss]

@rpg777

Here's what I found while triaging this issue:

Please don’t recreate the destructive drag just to gather evidence. If the diagnostic conversation/history contains private details, share it through Warp support and reference #14802; otherwise, a redacted transcript or log excerpt can be attached here.

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

1. Can you attach the already-captured diagnostic conversation/history or a redacted log excerpt showing the drag/drop sequence and the missing conversation afterward?
2. Was the item you dragged the original/root agent conversation tab, or a split-off child-agent conversation pane opened from within another conversation?

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 dragging an agent conversation pane onto the tab bar may remove the pane/conversation from the visible history after pane-move cleanup on macOS..

Triage summary

This is a plausible client-side bug in the interaction between agent conversation panes and tab/pane drag-and-drop. The report cites PaneHeaderDropped { drop_location: TabBar(...) } followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found on v0.2026.07.29.09.05.stable_02, which lines up with the pane-header drop and pane removal/focus paths.

Reproducibility

Medium. The report has a concrete action and diagnostic log sequence on macOS 15.7.7, but the issue still lacks attached primary evidence for the exact pre-drag pane state and post-drag conversation-list state. Because the reporter says this may delete history, they should not be asked to recreate the destructive drag just for evidence.

Likely code area

• app/src/pane_group/pane/view/header/mod.rs emits PaneHeaderDropped / DroppedOnTabBar for pane-header drags.
• app/src/workspace/view.rs handles pane_group::Event::DroppedOnTabBar, removes the source pane with remove_pane_for_move, and inserts it into a new/existing tab.
• app/src/pane_group/mod.rs contains remove_pane_for_move, focus_next_terminal_pane_and_activate_session, child-agent pane handling, and close/cleanup paths.
• app/src/ai/conversation_utils.rs, app/src/ai/blocklist/history_model.rs, and app/src/pane_group/pane/terminal_pane.rs are the relevant deletion/removal paths if a move is misclassified as a close/kill/delete.

What remains ambiguous

The current evidence supports a bad pane move/cleanup path, but not yet whether the conversation was actually deleted from persistence/cloud or became inaccessible because the pane/conversation ownership mapping was lost. The key missing detail is the diagnostic transcript/log excerpt the reporter mentioned and whether the dragged pane was a root/original agent tab or a split-off child-agent conversation pane.

Duplicate check

I scanned all open issues in warpdotdev/warp and did supplemental exact searches for PaneHeaderDropped, Unable to locate a panel to activate after close, and conversation-history/tab-bar wording. I did not find two or more likely duplicates, so this should not be marked duplicate.

Question reasoning

1. Can you attach the already-captured diagnostic conversation/history or a redacted log excerpt showing the drag/drop sequence and the missing conversation afterward? — The reporter says they have conclusive diagnostic history, and that evidence is needed without asking them to recreate a potentially destructive drag.
2. Was the item you dragged the original/root agent conversation tab, or a split-off child-agent conversation pane opened from within another conversation? — The code paths differ for ordinary panes versus split-off child-agent panes, and this determines whether the likely bug is generic tab-bar pane movement or child-agent pane ownership/re-adoption.

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

Powered by Oz

[rpg777]

LOL this whole bug has broken my conversations. So NO I don't have an easy way to give you the diagnostic info beyond what I pasted into the issue when I opened it. I am thoroughly done with you.

[oz-for-oss]

@rpg777

Here's what I found while triaging this issue:

Thanks for the added context. The pasted log signature points at Warp's pane drag/drop path rather than an intentional delete action, so this remains a plausible client-side bug. The exact drag source and target still matter because root agent panes and child/sub-agent panes use different move/close paths.

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

1. Can you attach the existing agent transcript you mentioned, redacted for private details?
2. Was the dragged item a whole agent pane/header, a child or sub-agent pane from an orchestration, or a conversation-list entry?

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 dragging an agent conversation pane onto the tab bar appears to run a pane move/close path that can leave the conversation missing from history without an explicit delete action..

Triage summary

This should stay routed as a macOS client bug spanning agent conversations and tab/pane management. The strongest evidence is the reported log sequence: PaneHeaderDropped { drop_location: TabBar(...) } followed by [PaneGroup] Unable to locate a panel to activate after close / Pane not found, with no reported explicit delete action.

Code inspection maps the log signature to the generic pane drag/drop path: app/src/pane_group/pane/view/header/mod.rs emits a tab-bar drop, app/src/workspace/view.rs handles DroppedOnTabBar, and app/src/pane_group/mod.rs removes the source pane via remove_pane_for_move. When the moved pane is the only pane in its source tab, remove_pane_for_move emits Exited { add_to_undo_stack: false }; the workspace Exited handler then closes the source tab while the move is still being processed. That fits the focus/pane-not-found errors.

The deletion mechanism is still not fully proven. The ordinary move detach path uses DetachType::Moved, which should not intentionally clear conversation history. Explicit hard deletion normally goes through app/src/ai/conversation_utils.rs and BlocklistAIHistoryModel::delete_conversation, or child-agent kill/remove paths. The most plausible next investigation is whether a dragged agent or child-agent pane loses its conversation ownership/re-adoption state during the source-tab close, especially around child-agent split-off handling.

Duplicate check: exact searches for the reported log strings and the drag-to-tab deletion symptom did not find two likely open duplicates. Nearby conversation-history issues such as #7943, #11769, and #11053 have different triggers, so this should not be marked duplicate.

Factory auto-implement: not eligible because this is a data-loss/data-integrity-sensitive bug and the exact source/target pane type is still ambiguous.

Question reasoning

1. Can you attach the existing agent transcript you mentioned, redacted for private details? — The transcript may show the exact drag instruction, the UI state, and any surrounding logs without asking the reporter to recreate the data-loss scenario.
2. Was the dragged item a whole agent pane/header, a child or sub-agent pane from an orchestration, or a conversation-list entry? — Those surfaces route through different move, close, and conversation-ownership paths, so this materially affects the likely root cause and repro path.

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

Powered by Oz