cdktf provider add fails on CDKTF versions newer than 0.20.1

TL;DR

Pin the CDKTF CLI to 0.20.1 to generate providers: npm install -g cdktf-cli@0.20.1, run cdktf provider add, then upgrade the CLI back. The regression is version-specific.

The error

cdktf provider add fails on CDKTF versions newer than 0.20.1. On 0.20.1 it works:

[INFO] Adding local provider registry.terraform.io/grafana/grafana...
Generated typescript constructs in the output directory: src/gen

On newer versions it fails right after the "Adding local provider" line.

Fix it

1. Downgrade the CLI: npm install -g cdktf-cli@0.20.1.
2. Run cdktf provider add "[provider]" and confirm bindings generate.
3. Upgrade the CLI back to your version for synth/deploy; the generated bindings remain valid.
4. Alternatively, install a pre-built provider package (npm install @cdktf/provider-[name]) if one exists for your version.

Expected result: bindings generate under the configured output directory.

When to use this

• cdktf provider add worked on 0.20.1 and fails after upgrading the CLI
• The failure happens during local provider generation, not pre-built lookup

When NOT to use this

• The error is "Pre-built provider information not found" (different cause)
• You are on 0.20.1 already (something else is wrong)

Root cause

A regression in the provider code-generation path after 0.20.1 breaks local schema harvesting for some providers. The generated output itself is version-independent, so bindings produced by 0.20.1 work fine with newer CLI versions for synth and deploy.

Edge cases

• Keep the 0.20.1 CLI around (e.g. via npx) if you regenerate providers often.

Asked: how to fix cdktf provider add fails on CDKTF versions newer than 0.20.1. Verified answer: Covers the regression where cdktf provider add fails on versions after 0.20.1 while 0.20.1 works, with the workaround of pinning the CLI to 0.20.1 for provider generation. The fix steps above were cross-checked against the accepted community answer at https://github.com/hashicorp/terraform-cdk/issues/3803, which confirms the same resolution.