Skip to main content

Allow uses to start, stop Workspaces but restrict Create and Delete

Updated

Problem

You want to restrict certain users so they can start, stop, and use workspaces, but cannot create or delete them. Workspace creation should be handled by managers via the API or another automated process.

You may have tried creating a custom role (for example, cr-workspace-startstop) with only start, stop, update, and read permissions on workspaces, assigned it to the user, and found that the user is still able to create workspaces.

Why Custom Roles Alone Do Not Work

In Coder, every user is automatically a Member, which is a shared default role that grants the ability to create, read, update, and delete their own workspaces.

Custom roles are additive — they grant additional permissions on top of the default Member role. They cannot be used to remove or override permissions already granted by Member.

Attempting to define a negative permission on a custom role returns:

{
  "message": "Failed to update role permissions",
  "detail": "org: invalid permission for action=\"create\" type=\"workspace\", no negative permissions"
}

Negative (deny) permissions are not allowed in user-defined custom roles.

Solution: Use the Built-in Organization Workspace Creation Ban Role

Coder ships a built-in organization role called Organization Workspace Creation Ban (organization-workspace-creation-ban) which uses internal negative permissions to override the Member role. Assigning it to a user denies the following actions on workspaces within that organization:

  • create
  • delete
  • create_agent
  • delete_agent

Other workspace actions (start, stop, read, update, SSH, etc.) remain available.

How to Assign

  1. Go to Deployment → Users (or the organization's user list).
  2. Edit the target user.
  3. Under Organization roles, select Organization Workspace Creation Ban in addition to their existing roles.
  4. Save.

You can also assign it via the API or CLI using the role name organization-workspace-creation-ban.

Expected UI Behavior

The role denies the underlying action, but some UI affordances are still rendered:

  • The New workspace dropdown is still visible, but it shows no templates for the restricted user.
  • The Delete button remains visible on workspaces, but the action fails when clicked.
  • Workspaces created on the user's behalf via the API (for example, by a manager or template admin) appear normally and the user can start, stop, and use them.

Notes

  • This role was added to Coder relatively recently; verify availability on your version. Confirmed present in Coder 2.28+ and 2.34.0.
  • The role assignment is currently surfaced on the user record, not within the custom-role editor.
  • If you need a different combination of deny actions, file a feature request — user-defined negative permissions are not supported today.

Related