lima-vm/lima · error

expected status of instance %#q to be %#q, got %#q

Error message

expected status of instance %#q to be %#q, got %#q

What it means

ToolSet.RegisterInstance only accepts instances whose Status is limatype.StatusRunning (validate at toolset.go:71-74). The MCP toolset needs a live VM to establish its SFTP client (newSFTPClient is called right after), so registering a stopped/exited/broken instance fails with this formatted error naming the expected and actual status.

Source

Thrown at pkg/mcp/toolset/toolset.go:72

	r, err := cmd.StdoutPipe()
	if err != nil {
		return nil, nil, err
	}
	if err = cmd.Start(); err != nil {
		return nil, nil, err
	}
	client, err := sftp.NewClientPipe(r, w)
	if err != nil {
		if cmd != nil && cmd.Process != nil {
			_ = cmd.Process.Kill()
		}
	}
	return client, cmd, err
}

func (ts *ToolSet) RegisterInstance(ctx context.Context, inst *limatype.Instance) error {
	if inst.Status != limatype.StatusRunning {
		return fmt.Errorf("expected status of instance %#q to be %#q, got %#q",
			inst.Name, limatype.StatusRunning, inst.Status)
	}
	if len(inst.Config.Mounts) == 0 {
		logrus.Warnf("instance %#q has no mount", inst.Name)
	}
	ts.inst = inst
	var err error
	ts.sftp, ts.sftpCmd, err = newSFTPClient(ctx, inst)
	return err
}

func (ts *ToolSet) RegisterServer(server *mcp.Server) error {
	mcp.AddTool(server, msi.ListDirectory, ts.ListDirectory)
	mcp.AddTool(server, msi.ReadFile, ts.ReadFile)
	mcp.AddTool(server, msi.WriteFile, ts.WriteFile)
	mcp.AddTool(server, msi.Glob, ts.Glob)
	mcp.AddTool(server, msi.SearchFileContent, ts.SearchFileContent)
	mcp.AddTool(server, msi.RunShellCommand, ts.RunShellCommand)

View on GitHub (pinned to dd909d0973)

Solutions

  1. Start the instance first: limactl start <instance>, then retry registration.
  2. Verify status with `limactl list` and pick an instance showing Running.
  3. If the instance is Broken, inspect `limactl start --debug <instance>` logs to fix the underlying VM problem before using MCP tools.

Example fix

// before
inst, _ := store.Inspect(ctx, "myvm")
ts.RegisterInstance(ctx, inst) // fails if not Running
// after
inst, _ := store.Inspect(ctx, "myvm")
if inst.Status != limatype.StatusRunning {
    if err := instance.Start(ctx, stdout, stderr, instName, nil, ...); err != nil { return err }
    inst, _ = store.Inspect(ctx, instName)
}
return ts.RegisterInstance(ctx, inst)
Defensive patterns

Strategy: validation

Validate before calling

inst, err := store.Inspect(ctx, instName)
if err != nil { return err }
if inst.Status != limatype.StatusRunning {
    return fmt.Errorf("start instance %q first (status: %s)", instName, inst.Status)
}
if err := ts.RegisterInstance(ctx, inst); err != nil { return err }

Type guard

func registerable(inst *limatype.Instance) bool { return inst != nil && inst.Status == limatype.StatusRunning }

Try / catch

if err := ts.RegisterInstance(ctx, inst); err != nil {
    if strings.Contains(err.Error(), "expected status") {
        return fmt.Errorf("instance %s is %s; run limactl start %s", inst.Name, inst.Status, inst.Name)
    }
    return err
}

Prevention

When it happens

Trigger: Calling RegisterInstance (from limactl mcp server startup or embedded code) with an *limatype.Instance whose Status is anything other than Running — e.g. "Stopped", "Exited", "Broken", or an instance that was never started.

Common situations: Running `limactl mcp myinstance` when the instance is stopped; scripting MCP setup right after `limactl create` without `limactl start`; the VM crashed so status dropped from Running; stale instance name typo hitting an unstarted instance.

Related errors


AI-assisted analysis of lima-vm/lima@dd909d0973 (2026-09-01). Data as JSON: /api/errors/bc5beb718c63eab4. Report an issue: GitHub.