hashicorp/terraform · error

no supported plugins for protocol 0

Error message

no supported plugins for protocol 0

What it means

Returned in providerFactories reattach handling (meta_providers.go:548). When Terraform reattaches to an externally-managed provider (TF_REATTACH_PROVIDERS) whose ReattachConfig reports protocol version 0 — common with sdk.v2 before go-plugin carried the version — Terraform assumes proto v5. If tfplugin.VersionedPlugins[5] is not registered, it returns "no supported plugins for protocol 0". This is a build/embedding problem, not an end-user config error.

Source

Thrown at internal/command/meta_providers.go:548

			HandshakeConfig:  tfplugin.Handshake,
			Logger:           logging.NewProviderLogger("unmanaged."),
			AllowedProtocols: []plugin.Protocol{plugin.ProtocolGRPC},
			Managed:          false,
			Reattach:         reattach,
			SyncStdout:       logging.PluginOutputMonitor(fmt.Sprintf("%s:stdout", provider)),
			SyncStderr:       logging.PluginOutputMonitor(fmt.Sprintf("%s:stderr", provider)),
		}

		if reattach.ProtocolVersion == 0 {
			// As of the 0.15 release, sdk.v2 doesn't include the protocol
			// version in the ReattachConfig (only recently added to
			// go-plugin), so client.NegotiatedVersion() always returns 0. We
			// assume that an unmanaged provider reporting protocol version 0 is
			// actually using proto v5 for backwards compatibility.
			if defaultPlugins, ok := tfplugin.VersionedPlugins[5]; ok {
				config.Plugins = defaultPlugins
			} else {
				return nil, errors.New("no supported plugins for protocol 0")
			}
		} else if plugins, ok := tfplugin.VersionedPlugins[reattach.ProtocolVersion]; !ok {
			return nil, fmt.Errorf("no supported plugins for protocol %d", reattach.ProtocolVersion)
		} else {
			config.Plugins = plugins
		}

		client := plugin.NewClient(config)
		rpcClient, err := client.Client()
		if err != nil {
			return nil, err
		}

		raw, err := rpcClient.Dispense(tfplugin.ProviderPluginName)
		if err != nil {
			return nil, err
		}

View on GitHub (pinned to c9def3e214)

Solutions

  1. Ensure the terraform binary registers VersionedPlugins[5] (the standard distribution does); if using a custom build, include the v5 plugin set.
  2. Upgrade the provider's go-plugin/sdk so ReattachConfig carries a non-zero ProtocolVersion (5 or 6), avoiding the version-0 fallback entirely.
  3. Use the managed provider discovery path (terraform init) instead of TF_REATTACH_PROVIDERS unless you are actively developing the provider.

Example fix

// before: reattach config reports protocol 0, no v5 map
 reattach := terraform.ReattachConfig{ /* ProtocolVersion unset */ }
// after: set the negotiated protocol version explicitly
 reattach := terraform.ReattachConfig{ ProtocolVersion: 5 /* or 6 */ }
Defensive patterns

Strategy: validation

Validate before calling

// When building a reattach provider config, set the protocol version.
 if cfg.ProtocolVersion == 0 {
     if _, ok := tfplugin.VersionedPlugins[5]; !ok {
         return errors.New("v5 plugin set not registered; set ProtocolVersion explicitly")
     }
 }

Prevention

When it happens

Trigger: Embedding Terraform as a library and supplying a provider via TF_REATTACH_PROVIDERS / reattach config whose protocol version is 0, while the VersionedPlugins map lacks a v5 entry; or running a custom terraform binary that did not register the v5 plugin set.

Common situations: Developing/debugging a provider with `tfprotov5` against a terraform binary that was compiled without the v5 plugin map; using an old sdk.v2 provider reattach config with a newer terraform build.

Related errors


AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/51e018bec79beeba. Report an issue: GitHub.