A Terraform CI job applied against the default workspace instead of `staging`. How does Terraform decide which CLI workspace is active, and how do you make that deterministic in a pipeline?

## Where the selection lives A CLI workspace selection is **local machine state**. When you run `terraform workspace select staging`, Terraform writes the name into `.terraform/environment` in the working directory. Nothing about that lands in your `.tf` files, your commit, or the backend's view of the world. That has two consequences. On a laptop, the selection persists silently across days — you can come back on Monday still selected into an environment you forgot about. On a runner, `.terraform` is created fresh by `init` (or restored from a cache), so unless the job selects a workspace, the run happens in `default`. ## Why the failure is quiet Nothing errors. `default` always exists, so `plan` and `apply` succeed against whatever state that workspace holds. Two variants of the bug show up in real pipelines: 1. The default workspace holds nothing, so the job proposes creating an entire environment from scratch. Loud, but only if someone reads the plan. 2. The default workspace *is* one of your real environments — very common, because the first environment ever built was the one nobody bothered to name. Then the staging pipeline applies staging's variables to that environment's state. ## Making it deterministic **Set `TF_WORKSPACE`.** Terraform honours this environment variable to select the workspace non-interactively, which suits CI because the value comes from the job definition, is visible in the job configuration, and cannot be forgotten by a step ordering mistake. **Or select explicitly after init**, and let failure be the default outcome: ```bash terraform init -input=false terraform workspace select staging # fails if it does not exist terraform plan -input=false -out=tfplan ``` Because the backend must be initialized before Terraform can enumerate workspaces, this step always comes after `init`, never before. **For ephemeral stacks**, Terraform 1.4 and later accept `terraform workspace select -or-create pr-1234`, which creates the workspace if it is missing. That is exactly right for a per-pull-request environment whose first run must bootstrap itself, and exactly wrong for long-lived environments — there a typo silently creates `stagng` with an empty state and builds a duplicate estate instead of failing. ## Related hygiene - Add a guard that the plan is non-empty-in-the-expected-way, or at minimum echo `terraform workspace show` into the job log so the audit trail records which state was touched. - Do not commit `.terraform`. Beyond the workspace file, it holds provider binaries and a cached backend configuration; a stale cached backend on a runner is its own class of confusion. - Remember the local counterpart of this bug: a developer applying from a laptop inherits whatever selection is on disk. Teams that keep workspaces at all usually also keep production out of them entirely, so the worst case of a wrong selection is a rebuilt sandbox. ## The one-line answer The active workspace is a local file, not a property of the repository — so any pipeline that does not state the workspace explicitly is running in `default` by accident.