zed-industries/zed · error

delete_session not supported

Error message

delete_session not supported

What it means

AcpAgentConnection.delete_session deletes a session server-side via an ACP DeleteSessionRequest, but only when the initialize handshake advertised that capability. The method's own guard returns this error immediately when supports_delete() is false, avoiding a protocol-level rejection from an agent that has no session/delete handling.

Source

Thrown at crates/agent_servers/src/acp.rs:607

                                .map(|dt| dt.with_timezone(&chrono::Utc))
                        }),
                        created_at: None,
                        meta: s.meta,
                    })
                    .collect(),
                next_cursor: response.next_cursor,
                meta: response.meta,
            })
        })
    }

    fn supports_delete(&self) -> bool {
        self.supports_delete
    }

    fn delete_session(&self, session_id: &acp::SessionId, cx: &mut App) -> Task<Result<()>> {
        if !self.supports_delete() {
            return Task::ready(Err(anyhow::anyhow!("delete_session not supported")));
        }

        let conn = self.connection.clone();
        let updates_tx = self.updates_tx.clone();
        let session_id = session_id.clone();
        cx.foreground_executor().spawn(async move {
            conn.send_request(acp::DeleteSessionRequest::new(session_id))
                .block_task()
                .await
                .map_err(map_acp_error)?;
            updates_tx
                .try_send(acp_thread::SessionListUpdate::Refresh)
                .log_err();
            Ok(())
        })
    }

    fn watch(

View on GitHub (pinned to bc538def45)

Solutions

  1. Gate delete UI and logic on connection.supports_delete() before calling delete_session
  2. Upgrade the agent implementation so it advertises session deletion in its capabilities
  3. Fall back to hiding the thread locally when server-side deletion is unavailable

Example fix

// before
connection.delete_session(&session_id, cx).await?;

// after
if connection.supports_delete() {
    connection.delete_session(&session_id, cx).await?;
} else {
    hide_thread_locally(&session_id);
}
Defensive patterns

Strategy: type-guard

Type guard

fn can_delete_sessions(connection: &AcpAgentConnection) -> bool {
    connection.supports_delete()
}

Try / catch

Check supports_delete() first; on the 'delete_session not supported' error fall back to local-only removal (hide the thread without a server-side RPC).

Prevention

When it happens

Trigger: delete_session invoked on a connection whose agent capabilities lack session deletion — typically a caller that does not check supports_delete() first (the guard makes the unsupported path explicit rather than relying on the caller).

Common situations: Third-party or custom ACP agents (claude-code/gemini bridges) built against older ACP versions; UI that shows a delete button for every registered agent regardless of capability.

Related errors


AI-assisted analysis of zed-industries/zed@bc538def45 (2026-08-16). Data as JSON: /api/errors/3a28b8b32b10a8c0. Report an issue: GitHub.