zed-industries/zed · warning

copilot is disabled

Error message

copilot is disabled

What it means

as_running() returns this bail when the CopilotServer enum is in the Disabled variant — the integration was turned off (or never enabled) rather than merely not yet started. It is distinct from 'still starting' (state machine, not a toggle) and from the Error variant (startup attempted and failed). Any API call that requires a live language server will keep failing with this message until Copilot is enabled and started.

Source

Thrown at crates/copilot/src/copilot.rs:77

    Starting { task: Shared<Task<()>> },
    Error(Arc<str>),
    Running(RunningCopilotServer),
}

impl CopilotServer {
    fn as_authenticated(&mut self) -> Result<&mut RunningCopilotServer> {
        let server = self.as_running()?;
        anyhow::ensure!(
            matches!(server.sign_in_status, SignInStatus::Authorized),
            "must sign in before using copilot"
        );
        Ok(server)
    }

    fn as_running(&mut self) -> Result<&mut RunningCopilotServer> {
        match self {
            CopilotServer::Starting { .. } => anyhow::bail!("copilot is still starting"),
            CopilotServer::Disabled => anyhow::bail!("copilot is disabled"),
            CopilotServer::Error(error) => {
                anyhow::bail!("copilot was not started because of an error: {error}")
            }
            CopilotServer::Running(server) => Ok(server),
        }
    }
}

struct RunningCopilotServer {
    lsp: Arc<LanguageServer>,
    sign_in_status: SignInStatus,
    registered_buffers: HashMap<EntityId, RegisteredBuffer>,
}

#[derive(Clone, Debug)]
enum SignInStatus {
    Authorized,
    Unauthorized,

View on GitHub (pinned to f4178619ac)

Solutions

1. Enable GitHub Copilot in the editor settings and re-run the action
2. Guard call sites: check the Copilot status before invoking operations, and hide/disable the UI affordance when Copilot is off
3. If disabled state is unexpected, check for settings layers (user/project/default) that turn it off

Example fix

// before
copilot.update(cx, |c, cx| c.sign_in(cx)); // bails 'copilot is disabled'

// after
use copilot::Status;
if !matches!(copilot.read(cx).status(), Status::Disabled) {
    copilot.update(cx, |c, cx| c.sign_in(cx));
}

use copilot::Status;

if matches!(copilot.read(cx).status(), Status::Disabled) {
    return Ok(()); // feature off — skip Copilot-dependent behavior entirely
}
let task = copilot.update(cx, |c, cx| c.sign_in(cx));

fn copilot_enabled(copilot: &Entity<Copilot>, cx: &App) -> bool {
    !matches!(copilot.read(cx).status(), Status::Disabled)
}

match result {
    Err(err) if err.to_string().contains("copilot is disabled") => {
        // configuration state — do not retry; prompt the user to enable Copilot
        prompt_enable_copilot();
    }
    other => other,
}

When it happens

Trigger: Calling sign_in, completions, or buffer-registration entry points on a Copilot instance whose settings/disable path put it into CopilotServer::Disabled — e.g. the user disabled GitHub Copilot in settings, or the feature is gated off in this build/configuration.

Common situations: User toggled Copilot off in settings but an editor feature (inline completions, sign-in command) still tries to use it; CI builds where Copilot is disabled by default; races where a disable happens between a UI check and the API call.

Related errors

• copilot is still starting
• copilot was not started because of an error: {error}
• Expected exactly one context server configuration
• GitHub Copilot native language server binary was not install
• unsupported Copilot language server platform: {platform}

AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/7e955376a487e8dc. Report an issue: GitHub.