How to fix the current package doesnt match any of the checksums previously recorded in the dependency lock file in Terraform

TerraformBEGINNERMEDIUMUpdated Dec 30, 2025· 147 views

Terraform's .terraform.lock.hcl file records provider package checksums to ensure security and consistency across different systems. A checksum mismatch occurs when the provider binary being installed doesn't match the recorded checksum, typically due to platform differences or provider version changes.

Quick fix

Fixes the current package doesnt match any of the checksums previously recorded in the dependency lock file

terraform providers lock -platform=darwin_amd64 -platform=darwin_arm64 -platform=linux_amd64 -platform=linux_arm64
  1. Verify the lock file exists
  2. Update lock file with checksums for all platforms using terraform providers lock
  3. Upgrade the lock file with terraform init -upgrade (if step 2 doesn't work)
  4. Commit the updated lock file
terraform — error
terraform providers lock -platform=darwin_amd64 -platform=darwin_arm64 -platform=linux_amd64 -platform=linux_arm64
the current package doesnt match any of the checksums previously recorded in the dependency lock file

What this error means

The checksum mismatch error is a security feature in Terraform that verifies the integrity of downloaded provider packages. When you run terraform init, Terraform downloads provider binaries and compares them against checksums recorded in your .terraform.lock.hcl file. If the checksums don't match, Terraform refuses to proceed to prevent installation of corrupted or unauthorized packages. This most commonly occurs when your lock file was created on a different platform (e.g., macOS) but you're now trying to init on another platform (e.g., Linux), because each platform has a different provider binary with a different checksum.

Typical symptoms

  • terraform init fails with 'checksum mismatch' error message
  • Error references specific provider like 'hashicorp/null v3.2.4'
  • Works fine on one machine but fails on another (different OS/architecture)
  • CI/CD pipeline fails at terraform init step
  • Recently upgraded Terraform version or provider version constraints

Common causes

  1. Lock file created on a different OS platform (macOS lock file used on Linux CI/CD)
  2. Lock file created on different CPU architecture (ARM64 created file used on x86_64)
  3. Provider version was updated but lock file wasn't regenerated and committed
  4. Team member ran terraform init and modified providers without updating lock file in version control
  5. Provider binary became corrupted in local cache or during download
  6. Switching between different provider registries or mirrors without updating lock file

How to fix "the current package doesnt match any of the checksums previously recorded in the dependency lock file"

1Verify the lock file exists

Check that your project has a .terraform.lock.hcl file. This file should be committed to your version control system. If it doesn't exist or was accidentally deleted, regenerate it by running terraform init.

2Update lock file with checksums for all platforms using terraform providers lock

Run the terraform providers lock command with flags for all platforms your team uses. For example, to support macOS (Intel), macOS (ARM), and Linux:

bash
terraform providers lock -platform=darwin_amd64 -platform=darwin_arm64 -platform=linux_amd64 -platform=linux_arm64

This command updates your .terraform.lock.hcl to include checksums for all specified platforms. After running this, commit the updated lock file to version control.

3Upgrade the lock file with terraform init -upgrade (if step 2 doesn't work)

If terraform providers lock isn't available or you need to update to newer provider versions, use terraform init -upgrade. This tells Terraform to ignore the existing lock file, download the latest compatible versions matching your constraints, and generate a new lock file with fresh checksums:

bash
terraform init -upgrade

After running this, always commit the updated .terraform.lock.hcl file to ensure your team has the same versions.

4Commit the updated lock file

After updating the lock file using either method above, commit it to version control:

bash
git add .terraform.lock.hcl
git commit -m 'Update Terraform lock file checksums for multi-platform support'
git push

Ensuring all team members work with the same lock file prevents future checksum mismatches.

5Run terraform init on a clean environment

On the machine or CI/CD system where you encountered the error, clean and reinitialize:

bash
rm -rf .terraform/
terraform init

This clears any cached provider binaries and verifies that the new lock file works correctly.

6Last resort: Delete and regenerate lock file (if nothing else works)

Only use this approach if the above steps don't resolve the issue, and only in controlled environments where you fully understand the implications. Deleting the lock file removes version pinning safeguards:

bash
rm .terraform.lock.hcl
rm -rf .terraform/
terraform init

This regenerates the lock file from scratch, but you lose the benefit of deterministic provider versions.

Advanced notes

Platform Considerations: Modern Terraform supports multi-platform lock files. When you run terraform providers lock with multiple -platform flags, it records checksums for all specified architectures in a single .terraform.lock.hcl file. This is the recommended approach for teams working across different operating systems.

Automation Best Practices: In CI/CD pipelines, always commit the lock file to version control and run terraform init without -upgrade to ensure deterministic deployments. Reserve -upgrade for controlled upgrades where you explicitly want newer provider versions.

Provider Mirror Sources: If you use private provider mirrors or registries, ensure the lock file's checksums match those mirrors. Some organizations use terraform providers lock -platform=... to explicitly validate that their mirror contains the correct provider packages.

Version Constraints: The lock file locks specific provider versions, not just major.minor versions. When you update provider version constraints in your configuration (e.g., from ~> 3.2 to ~> 4.0), you must regenerate the lock file. Always review lock file changes in git diffs before committing.

Frequently asked questions

What does "the current package doesnt match any of the checksums previously recor" mean?
The checksum mismatch error is a security feature in Terraform that verifies the integrity of downloaded provider packages. hcl file. If the checksums don't match, Terraform refuses to proceed to prevent installation of corrupted or unauthorized packages.
How do I fix "the current package doesnt match any of the checksums previously recor"?
Terraform's .terraform.lock.hcl file records provider package checksums to ensure security and consistency across different systems. A checksum mismatch occurs when the provider binary being installed doesn't match the recorded checksum, typically due to platform differences or provider version changes.
What causes "the current package doesnt match any of the checksums previously recor"?
Lock file created on a different OS platform (macOS lock file used on Linux CI/CD) Lock file created on different CPU architecture (ARM64 created file used on x86_64) Provider version was updated but lock file wasn't regenerated and committed
Is the "the current package doesnt match any of the checksums previously recor" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading