googleapis/mcp-toolbox · critical

toolbox crashed with the following error: %w

Error message

toolbox crashed with the following error: %w

What it means

runServe waits on select for either a server error on srvErr or ctx cancellation. If the running server emits an error while serving (not at startup), it is wrapped with 'toolbox crashed' and the process exits with that error.

Source

Thrown at cmd/internal/serve/command.go:123

		opts.Logger.InfoContext(ctx, "Server ready to serve!")
		if opts.Cfg.UI {
			opts.Logger.InfoContext(ctx, fmt.Sprintf("Toolbox UI is up and running at: %s://%s:%d/ui", protocol, opts.Cfg.Address, opts.Cfg.Port))
		}

		go func() {
			defer close(srvErr)
			err = s.Serve(ctx)
			if err != nil {
				srvErr <- err
			}
		}()
	}

	// wait for either the server to error out or the command's context to be canceled
	select {
	case err := <-srvErr:
		if err != nil {
			errMsg := fmt.Errorf("toolbox crashed with the following error: %w", err)
			opts.Logger.ErrorContext(ctx, errMsg.Error())
			return errMsg
		}
	case <-ctx.Done():
		shutdownContext, cancel := context.WithTimeout(context.Background(), 10*time.Second)
		defer cancel()
		opts.Logger.WarnContext(shutdownContext, "Shutting down gracefully...")
		err := s.Shutdown(shutdownContext)
		if err == context.DeadlineExceeded {
			return fmt.Errorf("graceful shutdown timed out... forcing exit")
		}
	}

	return nil
}

View on GitHub (pinned to 8cc6e09de2)

Solutions

  1. Read the wrapped root error for the crash reason
  2. Check process logs and system resources (memory, file descriptors) at crash time
  3. Upgrade the toolbox binary; check GitHub issues for the underlying error
  4. If caused by client load, add rate limiting or increase ulimits before restarting
Defensive patterns

Strategy: try-catch

Try / catch

select {
case err := <-srvErr:
    if err != nil {
        return fmt.Errorf("toolbox crashed with the following error: %w", err)
    }
case <-ctx.Done():
    // graceful shutdown path
}

Prevention

When it happens

Trigger: The serving goroutine pushes a non-nil error into srvErr — e.g., an accepted-connection handler failure, a fatal error inside Serve on one of the protocol servers, or the listener dying mid-run.

Common situations: Out of memory / resource exhaustion killing the listener, a panic in request handling surfacing as a server error, or a TLS/handshake misconfiguration appearing after startup.

Related errors


AI-assisted analysis of googleapis/mcp-toolbox@8cc6e09de2 (2026-09-05). Data as JSON: /api/errors/9539de94a49d25ab. Report an issue: GitHub.