State locking stops two Terraform operations from writing the same state at once. terraform force-unlock removes a lock manually, and HashiCorp says to use it only to release your own lock after automatic unlocking failed, because unlocking someone else's lock can cause multiple writers.
What locking does
If your backend supports it, Terraform locks the state for every operation that could write it. This prevents others from acquiring the lock and possibly corrupting the state. It happens automatically with no message, unless acquiring the lock takes longer than expected.
Not every backend supports locking. The backend documentation says which ones do, so check before you rely on it.
Why it matters for security
A corrupted or half written state can lead to a plan that destroys or recreates resources. In a shared pipeline, two simultaneous applies are also a way for a stale plan to overwrite a newer change. Locking is a control against accidental damage, and it supports change management.
The force-unlock command
If a run crashes, the lock can remain. Terraform prints a unique lock ID when unlocking fails. The force-unlock command requires that ID, which acts as a nonce so that locks and unlocks target the correct lock.
HashiCorp is blunt: be very careful. Unlock only your own lock after a failed automatic unlock.
Decision steps
- Find out who holds the lock, from the error message and your pipeline history.
- Confirm that run has really stopped, not just slowed down.
- If it is your run and it is dead, run force-unlock with the lock ID.
- If it belongs to someone else, ask them first.
- After unlocking, run a fresh plan before any apply.
Locks in team practice
Pair locking with a single place where applies run. If developers can apply from laptops while a pipeline also applies, locking helps, but it cannot stop a plan made against old code from being applied afterward. Review rules that route all applies through one pipeline do more than any flag.
The -lock=false flag
You can disable locking for most commands with -lock=false, but the documentation recommends against it. In a pipeline, forbid the flag in review rules.
Quick comparison
| Action | Risk | When |
|---|---|---|
| Wait | Low | A run is still in progress |
| force-unlock own lock | Low to medium | Your run died |
| force-unlock someone else's | High | Avoid unless you have confirmed no run is active |
| -lock=false | High | Avoid |
Quick check
Does every backend lock state?
No. Check the documentation for your backend.
What is the lock ID for?
It makes sure force-unlock targets the correct lock.
Should I plan again after force-unlock?
Yes. Run a fresh plan before applying, since state may have changed.
Safeguard offers SBOM and dependency scanning and policy gates that can block a pull request on findings, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
