how to fix terraform error

Not specified by the original author.

TL;DR

Use it deliberately, never as a reflex. .terraform.lock.hcl records the exact provider versions selected and their hashes. With it, installs are reproducible and tamper-evident. Run it when your team mixes macOS and Linux, or when CI runs on a different OS than your laptop, so all platforms have recorded hashes.

When to use

You are seeing this: It belongs in git next to your config. Use this skill when you run into "Terraform: treat .terraform.lock.hcl as a first-class artifact".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

How

The lock file is created and updated by terraform init. Key operations:

1. Commit it. It belongs in git next to your config. Do not gitignore it in root modules.
2. terraform init -upgrade re-resolves and rewrites the lock file with the newest versions allowed by your constraints. Use it deliberately, never as a reflex.
3. terraform providers lock regenerates lock entries for multiple platforms at once. Run it when your team mixes macOS and Linux, or when CI runs on a different OS than your laptop, so all platforms have recorded hashes.
4. Never hand-edit the hashes. If a hash looks wrong, delete the lock file and re-init, then review what changed with git diff.

Rules for agents

1. If the lock file is missing from a repo that should have one, say so. Do not silently re-init and move on.
2. After any provider constraint change, expect the lock file to change. Review the diff: version bumps you did not intend are a signal to stop.
3. A lock file that suddenly changes with no config change means someone ran -upgrade or the file was regenerated. Ask why before applying.
4. In CI, a fresh terraform init that rewrites the lock file means the committed file was stale. Fail loudly or commit the update, do not silently proceed.

Why

.terraform.lock.hcl records the exact provider versions selected and their hashes. Without it in version control, every terraform init on a fresh machine can pick different provider builds. With it, installs are reproducible and tamper-evident.

OpenTofu/Terraform dependency lock docs: the lock file records provider version selections; terraform providers lock updates the lock file; -upgrade forces re-resolution. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR

The failures come from the deltas: features added after the fork, different defaults, and migration friction. An agent that assumes identical behavior will misconfigure state locking or encryption. Both default to their own registries for unqualified sources. source = "hashicorp/aws" resolves against the configured registry; be explicit when a config moves between tools. Check which binary a repo actually uses before running commands.

When to use

You are seeing this: OpenTofu has built-in state and plan encryption (PBKDF2 key provider plus AES-GCM method). Use this skill when you run into "OpenTofu vs Terraform: what actually differs in 2026".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The deltas that matter

1. State encryption. OpenTofu has built-in state and plan encryption (PBKDF2 key provider plus AES-GCM method). Terraform has no equivalent native feature; it relies on backend-side encryption. Do not write OpenTofu encryption blocks in a Terraform config or vice versa.
2. S3 native state locking. OpenTofu supports use_lockfile = true on the S3 backend (conditional-write locking, no DynamoDB needed). Terraform's S3 backend historically uses dynamodb_table. Both tools can read each other's state, but the locking config is not portable.
3. removed blocks. Both support removing resources without destroying, but verify the exact syntax on your toolchain version before writing them.
4. Provider registry defaults. Both default to their own registries for unqualified sources. source = "hashicorp/aws" resolves against the configured registry; be explicit when a config moves between tools.
5. CLI command names differ (tofu vs terraform) but flags and workflows are intentionally compatible. CI scripts need the right binary name.

Rules for agents

1. Check which binary a repo actually uses before running commands. A repo with tofu in CI that you drive with terraform will fight over the lock file.
2. The OpenTofu migration guide covers state compatibility: state files are portable, but back up before switching tools on a live workspace.
3. Do not mix: one workspace, one tool. Alternating terraform apply and tofu apply on the same state invites lock-file and provider-resolution fights.

Why

OpenTofu is a fork of Terraform 1.5, so nearly all config works on both. The failures come from the deltas: features added after the fork, different defaults, and migration friction. An agent that assumes identical behavior will misconfigure state locking or encryption.

OpenTofu docs: built-in state/plan encryption via key providers (pbkdf2) and methods (aesgcm); S3 backend native locking via uselockfile=true using conditional writes; import blocks accept identity or id; moved-block semantics. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR

For "Error: Failed to get existing workspaces: AccessDenied: Access Denied": check the bucket policy and IAM policy for the four operations state needs: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the state bucket and key prefix. If locking uses DynamoDB, the identity also needs dynamodb:GetItem/PutItem/DeleteItem on the lock table. A 403 that only appears during apply (not plan) often means the lock table permissions are missing. The S3 403 that survives an IAM fix is usually KMS.

Error: Failed to get existing workspaces: AccessDenied: Access Denied
  status code: 403 ...

When to use

You are seeing this: ` Error: Failed to get existing workspaces: AccessDenied: Access Denied status code: 403... ` or on the S3 backend, 403s during init, plan, or state operations. Use this skill when you run into "Terraform: 403/AccessDenied on the backend is an IAM problem, not a Terraform problem".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

What you are seeing

Error: Failed to get existing workspaces: AccessDenied: Access Denied
  status code: 403 ...

or on the S3 backend, 403s during init, plan, or state operations. Terraform is telling you the credentials it has cannot read or write the state location. The config is almost certainly fine.

First response

1. Confirm which credentials Terraform is using. For AWS: check env vars, shared config, instance profile, in that precedence order. aws sts get-caller-identity tells you who you actually are.
2. Check the bucket policy and IAM policy for the four operations state needs: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the state bucket and key prefix. Missing any one of them produces a different confusing failure.
3. If locking uses DynamoDB, the identity also needs dynamodb:GetItem/PutItem/DeleteItem on the lock table. A 403 that only appears during apply (not plan) often means the lock table permissions are missing.
4. KMS-encrypted buckets need kms:Decrypt/kms:GenerateDataKey too. The S3 403 that survives an IAM fix is usually KMS.

Rules for agents

1. Do not "fix" a 403 by making the bucket public or widening the policy to s3:*. Scope the fix to the state prefix.
2. Never paste long-lived keys into backend config to dodge the issue. Fix the identity, not the config.
3. If it worked yesterday and 403s today, check for expired credentials, rotated keys, or a changed bucket policy before anything else.
4. Reproduce outside Terraform first: aws s3 ls on the bucket path. If the CLI 403s, Terraform will too, and you have eliminated Terraform from the suspect list.

S3 backend requires bucket/key/region config plus IAM permissions on the bucket and (for locking) DynamoDB table; KMS-encrypted buckets need key permissions. Verified against live S3 backend docs 2026-09-26. Verified against live docs 2026-09-26.