gitbutlerapp/gitbutler · error

Expected to be in open workspace mode

Error message

Expected to be in open workspace mode

What it means

`ensure_open_workspace_mode` guards the workspace-mode APIs (most virtual branch operations): it bails when the project's operating mode is not `OpenWorkspace`, which in practice means the project is still in edit mode. It is the mirror of `ensure_edit_mode` on the other side of the mode boundary.

Source

Thrown at crates/gitbutler-operating-modes/src/lib.rs:212

    let (outcome, conflict_kind) =
        but_workspace::legacy::merge_worktree_with_workspace(ctx, gix_repo, &ws)?;
    Ok(outcome
        .conflicts
        .iter()
        .filter(|c| c.is_unresolved(conflict_kind))
        .map(|c| c.ours.location().into())
        .collect())
}

pub fn in_open_workspace_mode(ctx: &Context, perm: &RepoShared) -> Result<bool> {
    Ok(operating_mode(ctx, perm)? == OperatingMode::OpenWorkspace)
}

pub fn ensure_open_workspace_mode(ctx: &Context, perm: &RepoShared) -> Result<()> {
    if in_open_workspace_mode(ctx, perm)? {
        Ok(())
    } else {
        bail!("Expected to be in open workspace mode")
    }
}

pub fn in_edit_mode(ctx: &Context, perm: &RepoShared) -> Result<bool> {
    Ok(matches!(operating_mode(ctx, perm)?, OperatingMode::Edit(_)))
}

pub fn ensure_edit_mode(ctx: &Context, perm: &RepoShared) -> Result<EditModeMetadata> {
    match operating_mode(ctx, perm)? {
        OperatingMode::Edit(edit_mode_metadata) => Ok(edit_mode_metadata),
        _ => Err(anyhow!("Expected to be in edit mode")),
    }
}

pub fn in_outside_workspace_mode(ctx: &Context, perm: &RepoShared) -> Result<bool> {
    Ok(matches!(
        operating_mode(ctx, perm)?,
        OperatingMode::OutsideWorkspace(_)

View on GitHub (pinned to caf1f223d3)

Solutions

1. Abort edit mode first (`abort_and_return_to_workspace`, with force only after user confirmation), then retry the workspace operation
2. Check `in_open_workspace_mode(ctx, perm)?` before calling and surface a clear mode error to the user
3. If the app should never have been in edit mode here, investigate how the mode was left set

Example fix

// before
ensure_open_workspace_mode(&ctx, &perm)?; // bails while in edit mode

// after
if in_edit_mode(&ctx, &perm)? {
    abort_and_return_to_workspace(&ctx, user_confirmed_discard(), &mut perm)?;
}
ensure_open_workspace_mode(&ctx, &perm)?;

if !in_open_workspace_mode(&ctx, &perm)? {
    return Err(anyhow::anyhow!("this operation requires open workspace mode"));
}

fn is_workspace_op_allowed(mode: &OperatingMode) -> bool {
    *mode == OperatingMode::OpenWorkspace
}

match ensure_open_workspace_mode(&ctx, &perm) {
    Err(err) if err.to_string().contains("open workspace mode") => {
        // abort edit mode first, then retry
    }
    other => other,
}

When it happens

Trigger: Calling open-workspace-only APIs (virtual branch create/update/apply and friends) while the project is in edit mode or before an edit-mode session was aborted.

Common situations: Programmatic workflows that enter edit mode and never exit; crashed edit-mode sessions leaving the mode set; tests that don't reset operating mode between cases.

Related errors

• Starting index state can only be fetched while in edit mode
• When using OpenRouter, you must provide a valid API key
• HTTP Error ${response.statusText}: ${text}
• Tearing off a branch requires a workspace common base
• Refusing to delete last named segment '{}' as it would leave

AI-assisted analysis of gitbutlerapp/gitbutler@caf1f223d3 (2026-08-20). Data as JSON: /api/errors/a0860e1ec7ebe434. Report an issue: GitHub.