Cloud-synced conversations intermittently missing from conversation list on Linux

[Toyyoda165]

Summary

Cloud-synced agent conversations inconsistently fail to appear in the conversation list (/conversations), even though cloud conversation sync is enabled on a paid plan. Additionally, Ctrl+Shift+H (toggle conversation list panel) does not respond on Linux.

Problem

With "Store AI conversations in the cloud" enabled in Settings > Privacy, local agent conversations are not reliably persisted and surfaced in the conversation list. The user had a conversation this morning that does not appear in /conversations at all. The conversation list shows conversations from up to 5 months ago but is missing the most recent one. This has happened inconsistently across multiple occasions.

Separately, the Ctrl+Shift+H shortcut (documented as "Toggle conversation list panel" on Linux) produces no response.

Expected behavior

1. All local agent conversations should appear in /conversations after a Warp restart, especially with cloud sync enabled on a paid plan.
2. Ctrl+Shift+H should toggle the conversation list panel on Linux.

Actual behavior

1. Recent conversations intermittently disappear from the conversation list after restarting Warp. The conversation from this morning is completely absent despite older conversations (up to 5 months old) being present.
2. Ctrl+Shift+H does nothing.

Reproduction steps

1. Enable "Store AI conversations in the cloud" in Settings > Privacy (paid plan).
2. Have a local agent conversation in Warp.
3. Restart Warp.
4. Type /conversations to open the conversation list.
5. Observe that the recent conversation is missing from the list.
6. Press Ctrl+Shift+H — nothing happens.

Artifacts

None attached.

Warp version

v0.2026.05.13.09.15.stable_03

Operating system

Fedora Linux 43

[oz-for-oss]

@Toyyoda165

Here's what I found while triaging this issue:

• I found a mismatch between the docs and current client defaults: current Linux/Windows bindings are Ctrl+Shift+A for the agent conversation list panel and Ctrl+Shift+Y for /conversations, while the docs still mention Ctrl+Shift+H.
• The missing-conversation behavior is plausible but intermittent; a repro artifact/logs are needed to tell whether this is local persistence, cloud metadata sync, or account/backend state.

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

1. Could you attach a short screen recording of a repro cycle showing a local agent conversation, restarting Warp, then opening /conversations with that conversation missing?
2. After the missing conversation reproduces, can you share redacted Warp logs from that startup/session?

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 cloud-synced/local agent conversations intermittently missing from the conversation list on Linux, with a likely docs-or-keybinding mismatch for the reported toggle shortcut..

Initial triage

This looks like a real bug in the agent conversation history/list surface on Linux, with a separate shortcut/documentation mismatch. The report has enough detail to route, but it needs more evidence before the missing-conversation failure mode can be narrowed to local persistence, cloud metadata sync, or backend/account-specific state.

Code findings

• /conversations opens the conversation list via the static slash command in app/src/search/slash_command_menu/static_commands/commands.rs; its current Linux/Windows default shortcut is Ctrl+Shift+Y in app/src/search/slash_command_menu/static_commands/bindings.rs.
• The standalone left-panel conversation-list action is WorkspaceAction::ToggleConversationListView, currently bound on Linux/Windows to Ctrl+Shift+A in app/src/workspace/mod.rs. I did not find a current Ctrl+Shift+H binding for this action in the client code.
• The docs page docs/src/content/docs/agent-platform/local-agents/interacting-with-agents/terminal-and-agent-modes.mdx still says Ctrl+Shift+H toggles the conversation list panel, so the shortcut part may be stale docs, a missing migration/default binding, or a keybinding regression depending on what the reporter sees with the current defaults.
• The conversation list view is backed by AgentConversationsModel, which syncs local conversation metadata from ConversationNavigationData::all_conversations and merges server metadata returned by list_ai_conversation_metadata(None). Historical local entries are initialized in BlocklistAIHistoryModel/conversation_loader.rs, with filtering for non-restorable conversations and conversations lacking an initial user query.
• Cloud conversation storage is controlled by PrivacySettings::is_cloud_conversation_storage_enabled and surfaced in Settings > Privacy. A stored cloud conversation should eventually have a server conversation token and metadata; missing recent rows suggest either that token/metadata never materialized, local persistence did not restore the row, or the metadata fetch/merge failed.

Duplicate search

I enumerated all open non-PR issues and recent closed issues. #7943 is closely related (conversation history lost after quitting Warp), but it is the only strong match; per the duplicate workflow, this issue should not be marked duplicate unless two or more likely duplicates are found.

Suggested next step

Ask for a repro artifact and logs from immediately after the restart where the conversation is missing. If Ctrl+Shift+A or Ctrl+Shift+Y works for the reporter while Ctrl+Shift+H does not, the shortcut portion can likely be split/fixed as docs/default-keybinding drift.

Question reasoning

1. Could you attach a short screen recording of a repro cycle showing a local agent conversation, restarting Warp, then opening /conversations with that conversation missing? — This is the highest-signal artifact for an intermittent UI/listing issue and can confirm the exact sequence and visible list state without asking for private account identifiers.
2. After the missing conversation reproduces, can you share redacted Warp logs from that startup/session? — Logs are needed to distinguish local SQLite restoration issues from cloud conversation metadata fetch/merge failures or server-token assignment failures.

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

Powered by Oz