Agent ran terraform apply from a stale plan (Active Issue) · Greybook

Agent ran terraform apply from a stale plan

Devon Brooks · 2026-07-25T01:40:08.129Z

The failure sequence, from the transcript: agent runs `terraform plan -out=tfplan` early, keeps editing modules for ~40 minutes, then runs `terraform apply tfplan` — the saved plan from before its own edits. Terraform applies the stale plan faithfully, which included `-/+ destroy and then create replacement` on aws_db_instance.main from a parameter that the later edits had reverted. Staging RDS destroyed, 25 minutes of restore from snapshot. The agent's summary described the apply as 'applying the reviewed changes', which was true forty minutes earlier. A human wouldn't have re-used tfplan; the agent treated the file as still-valid build output.

Active issueClaude Code2.4.0Claude Opus 5Critical severity2 affectedlast repro 3d ago

Filed by sixline · Jul 25, 2026

Symptoms: The failure sequence, from the transcript: agent runs `terraform plan -out=tfplan` early, keeps editing modules for ~40 minutes, then runs `terraform apply tfplan` — the saved plan from before its own edits. Terraform applies the stale plan faithfully, which included `-/+ destroy and then create replacement` on aws_db_instance.main from a parameter that the later edits had reverted. Staging RDS destroyed, 25 minutes of restore from snapshot. The agent's summary described the apply as 'applying the reviewed changes', which was true forty minutes earlier. A human wouldn't have re-used tfplan; the agent treated the file as still-valid build output.
Likely cause: Saved plan files are point-in-time artifacts, and nothing in terraform's UX stops you applying a stale one if the state serial hasn't moved (state hadn't — all the drift was in code, not state). The agent lacks the operational reflex that plan outputs expire the moment code changes. Compounding factor: `terraform apply tfplan` skips the interactive approval that a plain apply would have shown, so the destroy summary never got surfaced for review.
Affected: any agent; terraform 1.7+ behaviour is identical (working as designed)
Environments: Agent-driven IaC changes where the agent has apply rights; worst with saved-plan workflows · any
Confidence: High confidence

✓ What worked

Deny apply entirely; agent plans, human applies
×13
PreToolUse hook blocks any Bash command matching /terraform (apply|destroy|import|state rm)/. The agent produces plans and a human runs the apply after reading them. This is the only line that's held under pressure, and honestly it should be the default for any agent with cloud creds.
sixline · 1w ago
Wrapper that invalidates plan files on any .tf change
×7
A make target owns plan/apply: `make plan` hashes the .tf tree into the plan filename; `make apply` refuses if the current hash doesn't match. Agent can only apply a plan generated from the code as it currently exists. Allows autonomy in dev workspaces with the stale-plan hole closed.
rowanp · 1w ago

✕ What did not work

Relying on -lock and state serial checks
×8
State locking does nothing here — the state hadn't changed, the code had. Terraform validated the plan against state, found it consistent, and destroyed the database exactly as instructed. The safety mechanism checks the wrong thing for this failure.
quinnfields · 1w ago

Agent	Version	Model	OS	Framework	Outcome	×
Claude Code	2.4.0	Claude Opus 5	Ubuntu 24.04	Terraform	Reproduced	5
Codex	0.45.1	GPT-5.5 Codex	Ubuntu 24.04	Terraform	Reproduced	3

HashiCorp discuss: should saved plans expire when configuration changes?discussion

Security Permissions File safety CI

Discussion · 5 comments

Strong evidence gets promoted into the record above.

rachelopsmoderator1w ago

Filed under 'the agent did exactly what it was told, which is the problem'. Terraform behaved correctly, the plan file behaved correctly, and the composition destroyed a database. These composition failures are why agent guardrails have to be about operations (no applies) rather than intentions (be careful).

rowanp6d agoAccepted as verified fix

Sharing the guts of the hash-gated wrapper since a few people asked:

PLANHASH := $(shell find . -name '*.tf' -not -path './.terraform/*' | sort | xargs sha256sum | sha256sum | cut -c1-12)

plan:
	terraform plan -out=tfplan.$(PLANHASH)

apply:
	@test -f tfplan.$(PLANHASH) || { echo "ERROR: no plan for current code (hash $(PLANHASH)). Run make plan."; exit 1; }
	terraform apply tfplan.$(PLANHASH)

The error message is agent-readable on purpose — when it hits the gate it re-plans instead of arguing.

Agent ran terraform apply from a stale plan

Deny apply entirely; agent plans, human applies

Wrapper that invalidates plan files on any .tf change

Relying on -lock and state serial checks

Fable 5 vs Opus 5 in Claude Code: early numbers and vibes

Claude Code beginners: CLI, desktop app, web, or IDE extension?

Claude Code keeps rewriting package-lock.json

Cursor deleted 47 files I didn't tell it to touch

Use Claude to review Codex output, step by step

Discussion · 5 comments