fix(cli): proactively use active template version when require_active_version is set by f0ssel · Pull Request #22033 · coder/coder

f0ssel · 2026-02-10T15:07:41Z

Fixes #22030

Problem

When a template has require_active_version = true and a workspace is outdated, the web UI always shows "Update and start" as the only button (for all users including admins), but coder start starts with the old version. For admins, this silently succeeds on the stale version. For non-admins, it goes through a clunky 403→retry path. This also affects the VS Code extension, which calls coder start --yes under the hood.

Root Cause

buildWorkspaceStartRequest() in cli/start.go checks workspace.AutomaticUpdates == "always" but ignores workspace.TemplateRequireActiveVersion. The server-side autostart already ORs both settings together:

// coderd/autobuild/lifecycle_executor.go
func useActiveVersion(opts, ws) bool {
    return opts.RequireActiveVersion || ws.AutomaticUpdates == "always"
}

The CLI was missing the RequireActiveVersion check.

Fix

Add workspace.TemplateRequireActiveVersion to the existing OR condition:

// Before:
if workspace.AutomaticUpdates == codersdk.AutomaticUpdatesAlways || action == WorkspaceUpdate {

// After:
if workspace.AutomaticUpdates == codersdk.AutomaticUpdatesAlways || workspace.TemplateRequireActiveVersion || action == WorkspaceUpdate {

Now coder start and coder restart proactively use the active template version when require_active_version is set, matching the web UI and server autostart behavior. The 403→retry fallback remains as a safety net but is no longer the primary path for any user.

Testing

Updated enterprise/cli/start_test.go — all user types (owner, template admin, ACL admin, group ACL admin, member) now expect the active version when require_active_version is set, and verify the 403→retry message does NOT appear.

enterprise/coderd/workspaces_test.go

enterprise/coderd/templates_test.go

johnstcn

Changes look good to me.

geokat · 2026-02-10T18:23:15Z

Do we need a DB migration to make sure already existing workspaces are fixed too? Otherwise they won't be fixed until the admin re-toggles the setting for the template?

coderd/workspaces.go

sreya · 2026-02-10T20:01:52Z

coderd/templates.go

+		if req.RequireActiveVersion && !template.RequireActiveVersion {
+			err = tx.UpdateWorkspaceAutomaticUpdatesByTemplateID(ctx, database.UpdateWorkspaceAutomaticUpdatesByTemplateIDParams{
+				TemplateID:       template.ID,
+				AutomaticUpdates: database.AutomaticUpdatesAlways,
+			})
+			if err != nil {
+				return xerrors.Errorf("update workspace automatic updates: %w", err)
+			}


The only issue with doing this is that you lose the state of the workspace-scoped setting. So if someone toggles the template-scoped requiring automatic updates then you lose whatever setting the user set on the workspace. If someone toggles this off then all the workspaces will still be set to true right?

Yes this would be a force on, manual opt out

Ideally we keep the user's previously selected value. But at the same time, if toggling it in the template changes the user's value, I don't think that is a huge deal.

Right now when the template takes control, the user has a disabled field in the UI. So they can't change it, even if they wanted to change their user chosen fallback.

If someone is toggling the template setting and annoying users, we could revisit 🤷

sreya

@f0ssel could you explain where the bug manifested here? Were we not checking at build time that the version the user was trying to pass was the latest version if required by the template?

f0ssel · 2026-02-11T14:06:12Z

@sreya I think so, but I'm going to look more into the workspace scoped require_active_version because that feature is unfamiliar to me so I'm trying to understand what the original intent really was.

f0ssel · 2026-02-11T15:31:20Z

@sreya @johnstcn @geokat @Emyrk Thanks for the reviews, I think changing the workspace API value to satisfy #22031 may not be the ideal path forward, so I think matching the UI in consistent behavior would be a safer first step. I've updated the PR to reflect that change instead.

johnstcn

This is a better solution (making the CLI behaviour match the UI).

geokat · 2026-02-11T17:40:54Z

We may still not be addressing the user's issue. Based on the issue description and the conversation with @uzair-coder07, it seems the user is running coder start as a template admin (Owner) and expects it to behave the same way as the "Start" button in the frontend.

I think the misunderstanding is that the "Start" button behaves like coder update when the workspace version is not current, and the user expects coder start to behave exactly the same way.

f0ssel · 2026-02-17T16:50:33Z

Thanks for the context @geokat , I see that the UI doesn't give the option to start with the old version at all, so by having this option it's acting as a footgun. We can suggest using update, or maybe we can have start behave differently. Do you have a suggested UX change that could help align these?

geokat · 2026-02-17T17:59:34Z

I see that the UI doesn't give the option to start with the old version at all,

AFAICS template admins can pick an older version via meatball -> Change version, but it still requires changing the current version (even to an old one) before it takes effect. So the option is there, but it's hidden and not easy to use (you have to change to another version and then back to the one you want).

In general, I think having similar flows across frontends is the way to go. For example, the "Start" button in the webui could be a split button (depending on whether the user is a template admin) that starts on the current version by default but also allows updating (or the other way around).

I'm not sure about the best CLI UX... Maybe deprecate coder update and add an --update option (could be true by default) to coder start? 🤔

EDIT: Maybe we could also add --template-version=<ver> to coder start for even more parity with the webui.

…_version is set When a template has require_active_version enabled, coder start and coder restart now proactively use the active template version for all users (including admins), matching the web UI behavior where the only button shown is 'Update and start'. Previously, the CLI only checked workspace.AutomaticUpdates but ignored TemplateRequireActiveVersion. This caused admins using the CLI or VS Code extension to silently start on stale template versions. The fix adds TemplateRequireActiveVersion to the existing OR condition in buildWorkspaceStartRequest(), matching how server-side autostart already handles it. The 403->retry fallback remains as a safety net but is no longer the primary path for any user. Fixes #22030

github-actions bot assigned f0ssel Feb 10, 2026

f0ssel changed the title ~~fix: sync workspace automatic_updates with template require_active_version~~ fix: sync workspace automatic updates with template require active version Feb 10, 2026

f0ssel changed the title ~~fix: sync workspace automatic updates with template require active version~~ fix: sync workspace auto-update setting when template requires active version Feb 10, 2026

f0ssel changed the title ~~fix: sync workspace auto-update setting when template requires active version~~ fix: sync workspace automatic updates with template active version requirement Feb 10, 2026

f0ssel changed the title ~~fix: sync workspace automatic updates with template active version requirement~~ fix: synchronize workspace automatic updates with active version requirement Feb 10, 2026

f0ssel requested review from geokat and johnstcn February 10, 2026 16:12

johnstcn reviewed Feb 10, 2026

View reviewed changes

enterprise/coderd/workspaces_test.go Outdated Show resolved Hide resolved

enterprise/coderd/workspaces_test.go Outdated Show resolved Hide resolved

enterprise/coderd/templates_test.go Outdated Show resolved Hide resolved

enterprise/coderd/templates_test.go Outdated Show resolved Hide resolved

johnstcn approved these changes Feb 10, 2026

View reviewed changes

geokat reviewed Feb 10, 2026

View reviewed changes

coderd/workspaces.go Outdated Show resolved Hide resolved

sreya reviewed Feb 10, 2026

View reviewed changes

f0ssel closed this Feb 11, 2026

f0ssel force-pushed the ui-db-mismatch branch from 9c21b08 to 6ac0244 Compare February 11, 2026 14:27

github-actions bot locked and limited conversation to collaborators Feb 11, 2026

f0ssel changed the title ~~fix: synchronize workspace automatic updates with active version requirement~~ fix: document consistent require_active_version evaluation Feb 11, 2026

f0ssel changed the title ~~fix: document consistent require_active_version evaluation~~ fix(cli): proactively use active template version when require_active_version is set Feb 11, 2026

f0ssel reopened this Feb 11, 2026

johnstcn self-requested a review February 11, 2026 15:39

johnstcn approved these changes Feb 11, 2026

View reviewed changes

This comment was marked as resolved.

Sign in to view

f0ssel force-pushed the ui-db-mismatch branch from a0a98a4 to 9e792bf Compare February 25, 2026 00:41

f0ssel marked this pull request as ready for review February 25, 2026 00:41

f0ssel merged commit 6c16794 into main Feb 25, 2026
34 checks passed

f0ssel deleted the ui-db-mismatch branch February 25, 2026 00:51

Conversation

f0ssel commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Root Cause

Fix

Testing

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

johnstcn left a comment

Choose a reason for hiding this comment

Uh oh!

geokat commented Feb 10, 2026

Uh oh!

Uh oh!

sreya Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

f0ssel Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Emyrk Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

sreya left a comment

Choose a reason for hiding this comment

Uh oh!

f0ssel commented Feb 11, 2026

Uh oh!

f0ssel commented Feb 11, 2026

Uh oh!

johnstcn left a comment

Choose a reason for hiding this comment

Uh oh!

geokat commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

f0ssel commented Feb 17, 2026

Uh oh!

geokat commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

f0ssel commented Feb 10, 2026 •

edited

Loading

sreya Feb 10, 2026 •

edited

Loading

geokat commented Feb 11, 2026 •

edited

Loading

geokat commented Feb 17, 2026 •

edited

Loading