Skip to main content
troqcloud Workspace management is the boundary where identity, permissions, and deployment scope meet. In practice, this means the workspace commands are not just CRUD operations; they define which tenant context your teams can read from, deploy into, and administrate. For that reason, this surface should be tested with strict attention to role permissions and context resolution. The current workspace command group is exposed through:
At this stage, the public command set is create, list, show, update, archive, and transfer.

Context Model

There is no separate workspace use command in the current simplified CLI model. Workspace selection happens either per command with --workspace <id> or through project context in troq.toml (managed with troq config context use --workspace ...). This keeps the command surface smaller while still allowing deterministic targeting. When you run workspace commands without an explicit --workspace, the CLI resolves context from project-local settings where applicable. For sensitive changes, passing --workspace explicitly is still the safest operator habit.

Permission Requirements

Read operations and write operations are permission-gated differently. list and show are workspace-read paths, while update, archive, and transfer require workspaces.write. The permission key is plural: workspaces.write, not workspace.write. You can verify access quickly with:
If this returns allowed: false, assign an owner/admin role or update role-permission bindings in RBAC.

Command-by-Command Behavior

troq workspace list returns workspaces visible to the current principal. In table mode it is optimized for operators, including current-context hints when available. troq workspace show resolves one workspace by effective context and returns focused details for that target. troq workspace create creates a new workspace from a display name. This path is write-sensitive and will fail if authorization is missing. troq workspace update changes display metadata for the selected workspace and should be treated as a controlled write operation. troq workspace archive transitions the selected workspace to an archived state. This is operationally destructive in effect and should be executed only with explicit intent and permission confirmation in your operational process. troq workspace transfer changes ownership to another user ID and should be treated as a high-impact governance action.

Token Expiry During Workspace Operations

Workspace command execution now uses the refresh-capable auth path, which means access-token expiry should no longer break the operation with a confusing mid-command unauthorized error when refresh is still valid. If refresh state is invalid, re-login is still required:

Full Test Sequence

Use this exact sequence for end-to-end verification:
If you are validating context resolution at the same time, include:
config show and config context show should present a human-readable workspace name when resolution is available, with safe fallback behavior if lookup is temporarily unavailable. Last Updated: 2026-05-11