Library goroutines lack panic recovery (9 goroutines can crash host process)

[blackwell-systems]

Problem

The SDK spawns 9 goroutines across the mcp/ package that have no defer recover(). A panic in any of these goroutines (from user-provided tool handlers, middleware, or runtime errors like nil pointer dereferences) crashes the entire host process.

As a library, the SDK doesn't own the process, doesn't control the supervisor, and doesn't know what else runs in the same address space. A panicking goroutine takes down the consumer's HTTP server, metrics exporters, graceful shutdown hooks, and any other in-flight work.

Affected goroutines

File	Line	Purpose
mcp/server.go	976	Server.Run session handler
mcp/transport.go	215	Cancel propagation
mcp/transport.go	405	Transport goroutine
mcp/cmd.go	78	Command signal handling
mcp/sse.go	421	SSE connection handler
mcp/streamable.go	1816	handleSSE response processing
mcp/streamable.go	2000	handleJSON response processing
mcp/streamable.go	2011	handleSSE request processing
mcp/shared.go	608	Shared logic goroutine

Why this matters for MCP servers specifically

MCP servers commonly run embedded inside other processes: as sidecars, within web services, or spawned by AI coding tools. A tool handler with a nil pointer bug shouldn't be able to kill the host. The failure mode should be an error response to the client, not process death.

Proposal

Happy to submit a PR if this approach aligns with the project's philosophy. Questions:

• Do you prefer per-goroutine recovery, or a middleware/wrapper approach?
• Should recovery log via the SDK's structured logger, or stdlib log?
• Any goroutines in the list above that you'd intentionally leave unprotected?

[jba]

Your argument certainly makes sense. It is unfortunate that buggy packages can crash programs, programs which they don't control and about which they know nothing. (In Go, panics indicate bugs.) However, consider the alternatives: software bugs leave programs in an inconsistent state, behaving incorrectly, corrupting data, and disrupting other systems which themselves might start behaving poorly. The best choice out of these poor alternatives is to crash.

I looked at the first three of your examples. I don't see how they could panic without a serious program bug. For example, consider the function containing the goroutine at transport.go:405:

func newIOConn(rwc io.ReadWriteCloser) *ioConn {
	var (
		incoming = make(chan msgOrErr)
		closed   = make(chan struct{})
	)
	go func() {
		dec := json.NewDecoder(rwc)
		for {
			var raw json.RawMessage
			err := dec.Decode(&raw)
			// If decoding was successful, check for trailing data at the end of the stream.
			if err == nil {
				// Read the next byte to check if there is trailing data.
				var tr [1]byte
				if n, readErr := dec.Buffered().Read(tr[:]); n > 0 {
					// If read byte is not a newline, it is an error.
					// Support both Unix (\n) and Windows (\r\n) line endings.
					if tr[0] != '\n' && tr[0] != '\r' {
						err = fmt.Errorf("invalid trailing data at the end of stream")
					}
				} else if readErr != nil && readErr != io.EOF {
					err = readErr
				}
			}
			select {
			case incoming <- msgOrErr{msg: raw, err: err}:
			case <-closed:
				return
			}
			if err != nil {
				return
			}
		}
	}()
	return &ioConn{
		rwc:      rwc,
		incoming: incoming,
		closed:   closed,
	}
}

For this goroutine to panic, there would have to be a bug in the critical, highly tested encoding/json package, or in the Go runtime itself. In either case, your team, the Go MCP SDK team, and the entire Go community would want to know about it ASAP, because it could have far-reaching effects. Crashing your server is the right choice here.

There may be isolated cases where catching a panic is warranted, but I'm guessing all the examples in your list are like this one, and for those that aren't, a nil check or other bit of defensive code is a better choice than a recover. (That said, it is against our guidelines to add nil checks everywhere: they clutter the code and provide little benefit. We typically add one when we think a user is likely to misuse an API.) If we legitimately missed a check, where the function contract allows an input that the function body does not consider, then that is a bug, and you should file an issue for it.

[jba]

I forgot to mention that this is a reason to run your program in a managed environment that will spawn multiple processes, restart crashed ones, and track crashes deduped by stack trace. Then you can find and fix the frequent crashes while your system keeps running.