{{ message }}
fix: honor parameter defaults in --use-parameter-defaults and SSH auto-start#24591
Merged
jeremyruppel merged 5 commits intomainfrom Apr 24, 2026
Merged
fix: honor parameter defaults in --use-parameter-defaults and SSH auto-start#24591jeremyruppel merged 5 commits intomainfrom
jeremyruppel merged 5 commits intomainfrom
Conversation
jeremyruppel
added
the
community
jeremyruppel
removed
the
community
jeremyruppel
changed the title
jeremyruppel
force-pushed
the
fix/cli-honor-parameter-defaults
branch
2 times, most recently
from
56f4427 to
b6a1b10
Compare
jeremyruppel
changed the title
jeremyruppel
changed the title
jeremyruppel
force-pushed
the
fix/cli-honor-parameter-defaults
branch
from
b6a1b10 to
c1b2cd7
Compare
code-asher
approved these changes
Apr 23, 2026
jeremyruppel
force-pushed
the
fix/cli-honor-parameter-defaults
branch
from
b9ee383 to
779ac21
Compare
…efaults The auto-accept check used `parameterValue != ""` which rejected parameters with `default = ""` in Terraform. A parameter with Required==false always has a valid default, even if that default is an empty string. Use !tvp.Required instead to determine whether a usable default exists.
SSH is non-interactive, so when it auto-starts a stopped workspace it should never prompt for parameter values. Set useParameterDefaults=true on both the initial start and the forbidden/upgrade fallback paths.
Verifies that --use-parameter-defaults accepts parameters with default="" without prompting. Uses the classic parameter flow because the echo provisioner sets Required via proto fields, which the dynamic parameter evaluator does not read.
Verifies that the newly exposed --use-parameter-defaults flag works on start and update commands. Both tests push a new template version that adds a parameter with a default, then confirm the command completes without prompting.
jeremyruppel
force-pushed
the
fix/cli-honor-parameter-defaults
branch
from
779ac21 to
11e3d5d
Compare
Contributor
Author
code-asher
approved these changes
Apr 24, 2026
Comment on lines
+683
to
+685
Member
There was a problem hiding this comment.
We can make changes to make this work, I experimented with a poc here: 763f43a
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The CLI does not honor
defaultvalues on template parameters in two ways:--use-parameter-defaultsrejects empty-string defaults. The checkparameterValue != ""meansdefault = ""in Terraform falls through to an interactive prompt. In CI this causes an EOF error.--use-parameter-defaultsonly exists oncoder create. Thestart,update, andrestartcommands never wire it through. SSH auto-start passes emptyworkspaceParameterFlags{}, so users SSH-ing into a stopped workspace with new template parameters get stuck in an interactive prompt they cannot complete.Fix
1. Fix empty-string default detection and expose flag on all commands
Replace
parameterValue != ""with a check based on!tvp.Required. A parameter withRequired==falsealways has a valid default in Terraform, even if that default is"". Also respect CLI defaults provided via--parameter-default.Move
--use-parameter-defaultsfrom a standalone option oncreateinto the sharedworkspaceParameterFlagsstruct. This exposes the flag (andCODER_WORKSPACE_USE_PARAMETER_DEFAULTS) onstart,update, andrestartviaallOptions(). Wire it throughbuildWorkspaceStartRequestso the resolver receives it.2. SSH auto-start always uses defaults
Set
useParameterDefaults: trueon bothstartWorkspacecalls in the SSH auto-start path (initial start and the forbidden/upgrade fallback). SSH is non-interactive and should never prompt.Fixes https://linear.app/codercom/issue/DEVEX-180
Fixes #22272
Implementation notes
Scoping decisions
--yesdoes not imply--use-parameter-defaults: Making--yesauto-accept defaults exposes a validation gap in the dynamic parameter path (client-side validation happens during prompting, and skipping prompts bypasses it). This is deferred to a follow-up that also addressescodersdk.ValidateWorkspaceBuildParameterintegration in the resolver. Tracked in PLAT-114.--parameter,--rich-parameter-file, and--presetare resolved in stages 1-5 of the resolver, beforeresolveWithInputruns. No change needed for precedence.!tvp.RequiredvsparameterValue != "": TheRequiredfield is set by the Terraform provider based on whether adefaultis present. This is the canonical signal for "has a default," not the string value itself.