**TL;DR:** Provider plugin panics show as crashes or timeouts, not config errors. Teaches distinguishing a provider bug from bad config and the version-bisection triage. Read the stack trace: it names the provider and usually the resource and operation. Check the provider version and its issue tracker.

## The error

```text
panic: runtime error: invalid memory address or nil pointer dereference
...
```

## What you are seeing

```
panic: runtime error: invalid memory address or nil pointer dereference
...
```

or

```
Error: plugin did not respond
```

The provider process crashed or hung. Your config may be fine; the provider binary hit a bug, ran out of memory, or lost network access to its API mid-operation.

## First response

1. Read the stack trace: it names the provider and usually the resource and operation. A nil-pointer in the provider's Read function is a provider bug, full stop.
2. Check the provider version and its issue tracker. Crashes are the most-reported provider issue category; there is often a fixed release already.
3. Bisect by version: pin to the previous release and retry. If the crash disappears, you have your answer and your workaround (pin) until the fix lands.
4. Rule out the environment: OOM kills look like hangs ("did not respond"). Check runner memory, especially with large plans on small CI runners.

## Rules for agents

1. Do not rewrite config to dodge a provider crash until you have tried another provider version. Config churn around a provider bug wastes the most time.
2. Enable provider debug logging (`TF_LOG=DEBUG`) for one reproduction and attach it to the bug report. "It crashed" without logs gets closed.
3. If the crash happens during apply, check the real infrastructure before retrying. A crash after the API call succeeded leaves a real object with no state entry; retrying creates a duplicate.
4. Set a provider version pin as part of the fix so the next init does not reinstall the crashing version.

## When to use this

- You are seeing this exact error message; match the block above, not just part of it.
- The failing call matches the scenario in the title: Terraform.
- You want the fastest verified fix before digging through logs.

## When not to use this

- Your error text differs from the block above; close cousins often have different causes.
- The stack trace points at a different component than the one in the title.
- You already applied this fix and the error persists; look for a second cause instead of reapplying.

## Also seen as

- `Error: plugin did not respond`