Skip to main content

crewship issue

Issue tracking wired directly into agent dispatch. Use these commands to create and triage issues, manage labels, comments, relations, and sub-issues, and hand work to an assigned agent (start / stop / review). Issues can also be bound to a routine so a fixed workflow runs whenever the issue is started.
Alias: crewship issues

Subcommands


crewship issue list

List issues in the workspace with optional filters.
Output columns: ID, TITLE, STATUS, PRIORITY, ASSIGNEE, CREATOR, CREW, LABELS, UPDATED

crewship issue get

Show issue details including comments.
The identifier can be the issue identifier (e.g., BE-42) or the full ID. Output fields: Identifier, Title, Status, Priority, Crew, Assignee, Assignee Type, Description, Due Date, Mission Type, Labels, Comments count, Created By, Created, Updated, ID. Comments are displayed below the detail section.

Who created an issue

Every issue records its creator. The Created By field (and the CREATOR column in issue list) shows the resolved name, suffixed with (agent) when the issue was created by an agent through a tool call rather than by a human:
In --output json, the same information is available as the created_by object ({type, id, name}, where type is user or agent) plus authored_via (user_api or agent_tool_call).

crewship issue create

Create a new issue.

crewship issue update

Update an issue. Only changed flags are sent.

crewship issue delete

Delete an issue. Prompts for confirmation.
Deletion is permanent. --yes skips the prompt — reserve it for scripts.

crewship issue comment

Add a comment to an issue.
The comment body can be passed as positional arguments after the identifier, or via the --body flag (which takes precedence).

crewship issue labels

List all workspace labels.
Output columns: NAME, COLOR, GROUP

crewship issue start

Start an issue — dispatches work to the assigned agent.

crewship issue stop

Stop an issue — cancels running tasks.

crewship issue review

Review an issue — approve or request changes.

crewship issue comments

List comments on an issue. Hits GET /api/v1/crews/{crewId}/issues/{ident}/comments after resolving <identifier> to its crew via fetchIssue.
Output columns: ID, AUTHOR, TYPE, BODY (truncated to 60 chars, newlines flattened), CREATED.

crewship issue activity

Dump the mission-activity timeline for an issue. Hits GET /api/v1/crews/{crewId}/issues/{ident}/activity. Server caps the result at 50 rows DESC — pipe through jq if you need older history.
Output columns: WHEN (relative time), ACTOR (type/name), ACTION, DETAILS (truncated to 60 chars).

crewship issue runs

List the runs triggered by an issue — the data the dashboard’s issue “Runs” tab shows. Hits GET /api/v1/crews/{crewId}/issues/{ident}/runs after resolving <identifier> to its crew via fetchIssue.
Output columns: AGENT, TASK (truncated to 28), STATUS, STARTED (relative time), DURATION, RESULT (error message or result summary; ANSI-sanitised, truncated to 50 chars).

crewship issue changes

Show the base-branch git diff produced by the crew working an issue — the data the dashboard’s issue “Changes” tab renders. Hits GET /api/v1/crews/{crewId}/git-diff.
Without --patch, prints a per-file summary table (STATUS, FILE, +, −). When the crew workspace has no git repo, prints No git repository in this crew's workspace — nothing to diff.; with no changes against the base branch, prints No changes against the base branch.

crewship issue subtasks

List sub-issues — children whose parent_issue_id equals this issue’s id. Mirrors the SubIssues panel on the issue-detail page. Aliases: subissues, sub-issues.
Output columns: ID, TITLE (truncated to 50), STATUS, PRIORITY, ASSIGNEE.

crewship issue relate

Create a typed link between two issues. Wraps POST /api/v1/crews/{crewId}/issues/{ident}/relations.

crewship issue relations

List existing relations on an issue. Alias: relates.
Output columns: ID, TYPE, TARGET (identifier), TITLE (truncated to 40), STATUS.

crewship issue unrelate

Remove a relation by its relation ID (not the issue identifier). Hits DELETE /api/v1/relations/{id}.

Attach a GitHub pull request or GitLab merge request to an issue. Wraps POST /api/v1/crews/{crewId}/issues/{ident}/code-links.
The provider is recognised from the URL’s path (/pull/ → GitHub, /-/merge_requests/ → GitLab), so recognising a self-hosted instance of either needs no provider-specific configuration. Crewship then fetches the request through that provider’s API using a stored GITHUB / GITLAB credential in the workspace. Two things a self-hosted forge does still need: a credential labelled with its host (below), and — if it lives on a private/intranet address — the operator opt-in described in Git links. Without the opt-in the fetch is refused with blocked-host. For a self-hosted forge, set the credential’s account label to the forge’s host so it is matched by host:
Common failures (each a distinct RFC 7807 code): no-credential (412), blocked-host (422 — the forge is on a private address; see Git links), credential-rejected (502 — the token was revoked), rate-limited (429), already-linked (409). List an issue’s pull-request links. Aliases: code-links, prs.
Output columns: ID, STATE, REF (owner/repo#number), TITLE, BRANCH (source → target), SYNCED. A link whose last refresh failed shows its state as … (stale) — the data is the last one successfully fetched. Re-read a link’s state from its provider. Alias: refresh-link. State is never polled in the background; this is how you ask again.
A failed refresh keeps the last known state and records why on the link. Remove a link by its link ID (the first column of issue links).

crewship issue attach

Attach a local file to an issue. Wraps POST /api/v1/crews/{crewId}/issues/{ident}/attachments.
The type is decided by the file’s extension, against an allowlist — never by what the client claims, because a server that trusted a client-supplied content type would store and later serve markup from its own origin. Allowed: .txt .log .md .csv .tsv .json .yaml .yml .toml .xml .diff .patch .png .jpg .jpeg .gif .webp .avif .pdf .zip .gz .tgz. Anything else is refused with a 415 that lists the set. Maximum 25 MiB; a larger file is refused locally, naming its size, before anything is uploaded. Attaching the same bytes twice is the same attachment, so a retry is safe and does not add a second timeline entry. The agent working the issue can read what you attach — see Issue attachments.

crewship issue attachments

List an issue’s attached files. Alias: files.
Output columns: ID, FILENAME, TYPE, SIZE, BY ((agent) when an agent attached it), ADDED. Filenames are printed with control bytes stripped — they are chosen by whoever uploaded the file.

crewship issue attachment

Download one attachment by its attachment ID (the first column of issue attachments). Alias: download.
Without -o the bytes go to stdout, so the command composes with a pager or a pipeline. The server’s stored filename is never used to choose a local destination: it is a value someone else typed, and letting it name a path is how a download writes somewhere you did not ask for.

crewship issue detach

Remove an attachment by its attachment ID. Alias: unattach.
The stored bytes go too — but only if no other issue, comment or chat in the workspace still references the same file. Attachments are stored by content, so two issues carrying an identical file share one copy.

crewship issue bind-routine

Bind a routine slug to an issue — the server stores the underlying routine_id (pipeline UUID) so subsequent routine renames don’t break the link. Wraps PATCH /api/v1/crews/{crewId}/issues/{ident} with {"routine_id": <id>}.
The slug is resolved client-side via the workspace’s routine list before the PATCH, so a typo surfaces as routine "xyz": <404> instead of a silent no-op.

crewship issue unbind-routine

Clear the routine binding (server normalises empty string to SQL NULL).

crewship issue bulk update

Apply the same field updates to up to 100 issues in a single round-trip. Wraps PATCH /api/v1/issues/bulk. The 100-id cap is enforced both client-side (friendly error) and server-side (400).
At least one of --status / --priority / --assignee / --project / --labels must be supplied. Response surfaces as Bulk update applied to <updated>/<requested> issue(s). — the two counts differ when some IDs were 404 or 403.