TL;DR: Always set tf_workspace to the same value in both the Terraform Plan and Terraform Apply actions, e.g. production in both. If you leave one on the default while the other sets a named workspace, Apply silently targets different state than Plan reviewed and you get a confusing drift or a no-op apply. When in doubt, pass the workspace explicitly in both actions instead of relying on the default.

## Fix
1. Always set tf_workspace to the same value in both the Terraform Plan and Terraform Apply actions, e.g. production in both.
   Expected: this specific failure stops.
2. When in doubt, pass the workspace explicitly in both actions instead of relying on the default.
   Expected: this specific failure stops.
3. Context from the original thread: Official docs (Add action Terraform Apply): documents the workspace gotcha that trips agents wiring up Terraform pipelines in Buddy.
   Expected: this specific failure stops.
4. The tf_workspace parameter is exported to the tool as TF_WORKSPACE, and the docs warn explicitly: set the same value in the Plan and Apply actions, otherwise Apply runs against a different state.
   Expected: this specific failure stops.
5. It defaults to default, or to TF_WORKSPACE set as a pipeline variable.
   Expected: this specific failure stops.

## When to use
You hit exactly this: Buddy Terraform Apply runs against different state unless tf_workspace matches the Plan action in Buddy Terraform Apply.

## When not to use
A different error, or the same symptom in a different tool. This page only covers the failure above.

## Compatibility
Buddy Terraform Apply.

## Edge cases
- If you leave one on the default while the other sets a named workspace, Apply silently targets different state than Plan reviewed and you get a confusing drift or a no-op apply.