A workspace is the top-level tenant. Every other resource — crews, agents, credentials, projects, integrations — lives inside one. Aliases: ws. Defined in cmd/crewship/cmd_workspace.go.
The active workspace is stored in ~/.crewship/cli-config.yaml under workspace (slug or id). It is sent as workspace_id= on every API request by the CLI client, so switching workspaces is purely client-side — no server round-trip.
Auth:list, use, and get require crewship login; mutations additionally require an active workspace context. Role gates apply server-side — OWNER/ADMIN to update or invite, MEMBER+ to read.
Preferred reply language for agents (e.g. cs, en). Reinforced at the top and bottom of every agent prompt — including chat sessions, assignments, and pipelines — so the agent answers in this language.
Only flags you actually set are sent — passing nothing returns no fields to update.
Flag
Effect
--name <string>
Rename the workspace.
--slug <string>
Change the slug (URLs flip immediately).
--language <code>
Preferred reply language for agents (e.g. cs, en). Reinforced at the top and bottom of every agent prompt — including chat sessions, assignments, and pipelines — so the agent answers in this language.
The role flag is mirrored on the parent invite command so the shortcut form (workspace invite alice@example.com --role ADMIN) works without an explicit create.
crewship workspace list# SLUG NAME ID ROLE# acme-engineering * ACME Engineering ws_… OWNER# acme-design ACME Design ws_… MEMBERcrewship ws use acme-design# ✓ Default workspace set to: acme-design
workspace use validates that the slug actually exists and is accessible before writing the config, so a typo doesn’t quietly orphan every future command.
Per-member capabilities grant individual high-value actions (create routines, skills, credentials, …) to one member without promoting them to a wider RBAC role. They layer on top of the member’s role — a MEMBER can be handed routine.create while everyone else in that role stays chat-only.Aliases: caps, capability. ADMIN+ required to mutate; the CLI exits non-zero on a 403 so a misconfigured CI pipeline fails loudly. Capabilities are workspace-scoped — a user in multiple workspaces is configured separately in each.The chat capability is always implied and cannot be granted or revoked individually; removing chat means removing the member entirely (workspace member remove). The OWNER target is immutable, and you cannot mutate your own row (downgrade-then-restore defence).Valid capability strings: chat, routine.create, skill.create, credential.create, credential.rotate, issue.create, memory.write.
Grant one or more capabilities incrementally (existing grants preserved).
capabilities revoke <user-id> <cap> [<cap>...]
2+
Revoke one or more capabilities incrementally (other grants preserved).
capabilities preset <user-id> <chat|power|admin>
exactly 2
Replace the member’s capability set with a named bundle (overwrites existing grants).
Bundles map to common combinations:
Bundle
Capabilities
chat
chat-only baseline (default for new MEMBERs).
power
chat + routine.create + issue.create + memory.write (trusted team members).
admin
full set, including credential.create + credential.rotate.
crewship workspace member capabilities list usr_abc123crewship workspace member caps grant usr_abc123 routine.create issue.create memory.writecrewship workspace member caps revoke usr_abc123 memory.writecrewship workspace member caps preset usr_abc123 power
Unknown capability strings are rejected server-side (400, typo guard). Revoking chat is rejected by the server. The list command prints USER, ROLE, CAPABILITIES columns; mutations print the resulting capability set.
