Both terraform plan and terraform apply acquire the state lock. Plan needs it because it refreshes state and may write the refreshed state back. A plan process killed without cleanup, a common outcome of a cancelled CI job, leaves the lock held with no owner.
The next operation fails with Error acquiring the state lock, printing the lock ID, the operation, who created it, and when. terraform force-unlock LOCK_ID releases it, and the ID must be passed explicitly precisely so it cannot be run reflexively.
Before forcing, confirm no apply is actually running, because force-unlocking a live apply invites two writers. The -lock-timeout=5m flag makes an operation wait rather than fail immediately, which is the right setting for CI where a queue of runs is expected. Passing -lock=false disables locking entirely and should be reserved for read-only inspection against a state nobody else is touching. Since Terraform 1.x, terraform plan -refresh=false skips the refresh but still takes the lock.