aaif-goose/goose · error · anyhow::Error

ACP agent does not support session/load

Error message

ACP agent does not support session/load

What it means

A ClientRequest::LoadSession (session resumption carrying a session_id) was dispatched, but the agent's InitializeResponse did not advertise the load_session capability (init_response.agent_capabilities.load_session was falsy). The provider guards the LoadSessionRequest behind that capability flag and fails fast instead of sending an RPC the agent would reject.

Source

Thrown at crates/goose/src/acp/provider.rs:1314

            } => {
                let result = if supports_load {
                    let mcp_servers =
                        filter_supported_servers(&config.mcp_servers, &mcp_capabilities);
                    cx.send_request(
                        LoadSessionRequest::new(session_id.clone(), config.work_dir.clone())
                            .mcp_servers(mcp_servers),
                    )
                    .block_task()
                    .await
                    .map(|response| {
                        NewSessionResponse::new(session_id.clone())
                            .modes(response.modes)
                            .config_options(response.config_options)
                            .meta(response.meta)
                    })
                    .map_err(anyhow::Error::from)
                } else {
                    Err(anyhow::anyhow!("ACP agent does not support session/load"))
                };
                let result = match result {
                    Ok(session) => {
                        session_ids.push(session.session_id.clone());
                        apply_session_config_options(&config, &cx, session.session_id.clone())
                            .await?;
                        apply_session_mode(&config, &goose_mode, &cx, session).await
                    }
                    Err(error) => Err(error),
                };
                log_undelivered(response_tx.send(result), AGENT_METHOD_NAMES.session_load);
            }
            ClientRequest::CloseSession { session_id } => {
                if supports_close {
                    if let Err(error) = cx
                        .send_request(CloseSessionRequest::new(session_id.clone()))
                        .block_task()
                        .await

View on GitHub (pinned to 3810898a74)

Solutions

  1. Start a fresh session instead of resuming: drop the stored session id so a session/new is issued
  2. If resumption matters, use or upgrade to an agent that advertises session/load in its initialize response
  3. Check the agent's documented capabilities and align the client's resume behavior with them

Example fix

# before
session_id: "old-session-uuid"   # agent cannot load sessions

# after
# start a new session: remove the session id from the resume request
session_id: null
Defensive patterns

Strategy: type-guard

Type guard

fn supports_session_load(init: &InitializeResponse) -> bool {
    init.agent_capabilities.load_session
}

if !supports_session_load(&init_response) {
    // start a new session instead of LoadSession
}

Try / catch

match load_result {
    Err(e) if e.to_string().contains("session/load") => {
        tracing::warn!(%e, "agent cannot resume sessions; starting fresh");
        start_new_session().await
    }
    other => other,
}

Prevention

When it happens

Trigger: Configuring goose to resume a previous ACP session (passing a stored session id) while the configured agent only supports session/new — e.g. a minimal agent that keeps no state, or one built on an older ACP SDK without session persistence.

Common situations: Switching from a stateful agent (goose itself, or an editor agent) to a stateless one while the client still tries to resume the last session id; upgrading/downgrading an agent changes its advertised capabilities.

Related errors


AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/79be4672f715eba9. Report an issue: GitHub.