crewship workspace
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.
~/.crewship/cli-config.yaml under workspace (slug or id). It is sent as workspace_id= on workspace-scoped API requests by the CLI client. Switching workspaces writes local config and, when authenticated, validates the slug or ID against the server.
Auth:
list, get, and create require crewship login. update, all member operations, and invite additionally require an active workspace. use writes the local config and validates the slug or ID against the server when you’re already logged in. Role gates apply server-side — OWNER/ADMIN to update or invite, OWNER only to delete, MEMBER+ to read.Subcommands
crewship workspace get [slug-or-id]
Show details for the specified workspace, or for the active workspace when no
argument is supplied.
Name, Slug,
Language, Allow privileged credentials, ID, and Created; machine
formats use the corresponding API fields id, name, slug, created_at,
preferred_language, and allow_privileged_credentials.
Flags
workspace create
workspace update
Only flags you actually set are sent — passing nothing returns no fields to update.
workspace delete
Deletes a workspace and everything under it. Soft-delete with cascade over
crews and agents; OWNER only, and refused if it is your only workspace.
workspace member add
Which id do the member commands take?
workspace member list prints two ids per row and they are not
interchangeable at the API:
So
member add takes a user id while the endpoints behind member role
and member remove match only a membership row. Passing the user id used
to answer a bare Member not found — which reads as “that person is not in
this workspace” rather than “wrong id”, and cost a test suite its most
important assertion (#1829).
Both commands now accept either column and resolve it for you. An argument
that is in neither is refused by name before any request goes out:
workspace member list --format json carries the address in a flat email
field and in the nested user.email the server sends. The flat field used
to be present and always empty — a shape that silently broke every
jq 'select(.email == …)' written against it.
workspace member role
<ROLE> is one of OWNER, ADMIN, MANAGER, MEMBER, VIEWER
(case-insensitive). MANAGER+ only, and subject to the server ladder:
you can only grant a role below your own, cannot modify a member ranked
above you, and cannot demote the last OWNER.
workspace member remove
workspace invite / workspace invite create
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. No mailer is wired for this command.
crewship workspace invite create <email>
Record a workspace invitation for an email address. No email is sent; use
workspace member invite when account provisioning and a setup link are
needed.
On success the CLI prints
Invitation recorded for <email> (<role> role).
followed by a warning that no email was sent.
workspace member invite
This provisioning command is distinct from workspace invite: it creates the
account when needed, adds the membership, and prints a one-time setup link.
Examples
List + switch
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.
Create a workspace
Update a workspace
Delete a workspace
409 if it is your only workspace, and with 403 if you are
not the OWNER.
Member management
crewship admin list-users or the web UI’s user table.
workspace member capabilities
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 dashboard equivalent is Settings → Members: one row per person, expanded to reveal that member’s role and their eight capability grants side by side. The collapsed row summarises the grants so a capability stays comparable across the roster without expanding every row. Presets apply to the whole workspace from the card header, with a before/after diff for every member they would change.
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.
Subcommands
crewship workspace member capabilities grant <user-id> <capability> [<capability>...]
Grant one or more capabilities incrementally; existing grants are preserved.
chat, routine.create, skill.create,
credential.create, credential.rotate, issue.create, and memory.write.
On success it prints <user-id> (<role>): <capabilities>.
crewship workspace member capabilities revoke <user-id> <capability> [<capability>...]
Revoke one or more capabilities incrementally; other grants are preserved.
chat is rejected because chat is always implied; remove the
member instead. On success it prints <user-id> (<role>): <capabilities>.
crewship workspace member capabilities preset <user-id> <chat|power|admin>
Replace the member’s capability set with the named bundle, overwriting
existing grants.
chat, power, or admin,
with no command-specific flags. On success it prints
<user-id> (<role>): <capabilities>.
Bundles map to common combinations:
400, typo guard). Revoking chat is rejected by the server. The list command prints USER, ROLE, CAPABILITIES columns; mutations print the resulting capability set.
Invitations
invite <email>) and the explicit form (invite create <email>) share one implementation, so role flags behave identically on both.
Common errors
Common errors and what they mean
Common errors and what they mean
workspace "X" not found or not accessible—workspace usevalidated against/api/v1/workspacesand your token has no membership.--name is required—createneeds at least a name.no fields to update—updatewas called without any of--name/--slug/--language/--allow-privileged-credentials/--credential-audit-retention-days/--audit-log-retention-days.no workspace selected—updateran without an active workspace. Runcrewship workspace usefirst or pass--workspace.
See also
crewship login—crewship login --workspace <slug>sets the workspace at login time.crewship config— direct access to theworkspaceconfig key.crewship admin— cross-workspace operations (only OWNER on the workspace itself, or instance admin).- Workspaces API —
GET /api/v1/workspaces.