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
- Start the instance first: limactl start <instance>, then retry registration.
- Verify status with `limactl list` and pick an instance showing Running.
- 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
- Check `limactl list` for Running status before limactl mcp.
- Automate start-then-register instead of assuming the VM is up.
- Re-inspect the instance (store.Inspect) to refresh Status — don't cache stale values.
- Treat Broken status as a VM failure to debug, not an MCP problem.
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
- instance %#q is stopped, run `limactl start %s` to start the
- instance not registered
- instance not registered
- invalid value for static parameter: %#q
- invalid parameter %#q, expected `static=` followed by a bool
AI-assisted analysis of lima-vm/lima@dd909d0973 (2026-09-01).
Data as JSON: /api/errors/bc5beb718c63eab4.
Report an issue: GitHub.