hashicorp/terraform · error
The "remote" backend does not support the %q operation.
Error message
The "remote" backend does not support the %q operation.
What it means
The default branch of Operation()'s switch on op.Type: any operation type that is not Plan, Apply, or Refresh. It signals the remote backend does not implement that operation kind. In practice this is rarely hit because the CLI only queues known operation types, but it guards against unknown/unimplemented operation types.
Source
Thrown at internal/backend/remote/backend.go:803
return b.local.Operation(ctx, op)
}
// Set the remote workspace name.
op.Workspace = w.Name
// Determine the function to call for our operation
var f func(context.Context, context.Context, *backendrun.Operation, *tfe.Workspace) (*tfe.Run, error)
switch op.Type {
case backendrun.OperationTypePlan:
f = b.opPlan
case backendrun.OperationTypeApply:
f = b.opApply
case backendrun.OperationTypeRefresh:
return nil, fmt.Errorf(
"\n\nThe \"refresh\" operation is not supported when using the \"remote\" backend. " +
"Use \"terraform apply -refresh-only\" instead.")
default:
return nil, fmt.Errorf(
"\n\nThe \"remote\" backend does not support the %q operation.", op.Type)
}
// Lock
b.opLock.Lock()
// Build our running operation
// the runninCtx is only used to block until the operation returns.
runningCtx, done := context.WithCancel(context.Background())
runningOp := &backendrun.RunningOperation{
Context: runningCtx,
PlanEmpty: true,
}
// stopCtx wraps the context passed in, and is used to signal a graceful Stop.
stopCtx, stop := context.WithCancel(ctx)
runningOp.Stop = stop
View on GitHub (pinned to c9def3e214)
Solutions
- Use a supported operation: plan or apply (refresh is explicitly rejected with its own message; use apply -refresh-only).
- If embedding the backend in Go code, only pass backendrun.OperationTypePlan or OperationTypeApply.
- Check for a terraform version mismatch where a newer CLI sends an op type this backend version doesn't recognize — align CLI/backend versions.
Defensive patterns
Strategy: validation
Validate before calling
switch op.Type {
case backendrun.OperationTypePlan, backendrun.OperationTypeApply:
// proceed
default:
return fmt.Errorf("unsupported operation: %s", op.Type)
} Type guard
func isSupportedOp(t backendrun.OperationType) bool {
switch t {
case backendrun.OperationTypePlan, backendrun.OperationTypeApply:
return true
}
return false
} Prevention
- When embedding the backend, only queue OperationTypePlan or OperationTypeApply.
- Keep the CLI/backend versions aligned so new op types are recognized.
- Add a unit test asserting supported operation types for your integration.
When it happens
Trigger: An operation type outside the supported set (e.g. a future or internal OperationType constant) reaches Operation(); the switch has no case for it and falls to default.
Common situations: Running an unsupported or experimental subcommand against the remote backend; a code change introduced a new OperationType not yet wired into the remote backend; embedding the backend in custom tooling that passes an op.Type the backend doesn't handle.
Related errors
- Remote workspace Terraform version %q does not match local T
- The "refresh" operation is not supported when using the "r
- default workspace not supported You can create a new workspa
- failed to append certs
- the secret name %v is invalid, {validationErrors} This is a
AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07).
Data as JSON: /api/errors/a21aee852d1b38e1.
Report an issue: GitHub.