Skip to main content

crewship work

Agent webhook work is recorded before its runtime starts. Chat, routine webhooks and other producers are not yet covered by this ledger. crewship work reads that ledger, so “we never received it”, “we received it and filtered it out”, and “it ran and failed” are three different answers instead of one shrug. The full API contract is in the Work Items reference.
Three identifiers, routinely confused: Nothing these commands print contains the accepted input, a webhook payload, or model output. A work item’s input is, for a chat source, the conversation itself — you get its input_sha256 instead.

crewship work list

List work items in the current workspace, at most 100 per page.
Output columns: ID, STATE, SOURCE, EVENT, AGENT, ATTEMPTS, CREATED AGENT is the agent’s name, prefixed (deleted) once the agent was removed — with its id when no record of it remains. EVENT is the webhook event a delivery carried (for a replay, its original’s). The capacity class, crew, duration and cost are in -f json. A misspelt --state is refused rather than answered with an empty page — “nothing is running” is the wrong answer to a typo. When more rows remain the command prints the exact --after invocation that continues. needs_reconciliation deserves a look whenever it appears: it means a runtime may still be alive under a locator nobody has verified, and it keeps holding its capacity until somebody resolves it.

crewship work get <work-id>

Show one work item, every attempt, and its whole history.
The item names its agent and crew (prefixed (deleted) once removed), the event, and — once it has finished — its duration and cost. The attempt rows carry the run id (the same identifier the journal indexes), the lease and its owner, the runtime locator recovery consults before deciding a process is gone, the cost, and how the attempt ended. The history is append-only, in sequence order, and includes any recorded cancel request.

crewship work cancel <work-id>

Ask for a work item to stop. Safe to repeat.
Cancelling is a request, not an immediate result. The command reports which of three things happened: A running chat turn (host_chat_turn) is stopped by the server that runs it: it notices the request within about two seconds, stops the agent process and settles the item as cancelled from the observed exit. Cancelling does not undo external effects that already happened.

crewship work replay <work-id>

Create a new work item from a finished one.
This is not a retry. A retry keeps the work id and mints a new run id, and the queue does that on its own for a repeatable failure. A replay is a new authorization: the new item runs under your identity, carries replay_of and your reason, and re-uses the original input. Terminal history is never rewritten. Refusals come with an explanation rather than an opaque failure:
  • Replaying work that has not finished. Cancel it first.
  • Replaying a chat turn (host_chat_turn). Nothing in the work queue runs chat turns, so a copy would never start; send the message again in its chat.
  • Replaying webhook-sourced work whose raw payload has passed its retention. The delivery record survives the payload, so “we received it, we can no longer replay it” stays distinguishable from “we never saw it” — but only the sender can produce the bytes again.

crewship work deliveries summary

Count the recorded calls per endpoint — agent, routine and page triggers alike — split into accepted and ignored. This is the number the Triggers table shows beside each trigger.
Output columns: ENDPOINT, KIND, CALLS, ACCEPTED, IGNORED, LAST CALL

crewship work deliveries list

List recorded inbound webhooks, at most 100 per page.
Output columns: ID, AGENT, PROFILE, EVENT, DECISION, WORK, WORK STATE, PAYLOAD, RECEIVED AGENT names the endpoint’s agent; an endpoint of another kind reads as its kind and id (routine rt_…). WORK STATE is the state of the work item the delivery became, so an accepted delivery whose work failed reads as such. Deliveries the filter rejected are listed too, with their reason and no work id: a ping or a filtered event is auditable rather than invisible. --endpoint together with --source-id asks the identity question — “did you receive this one” — and answers with zero or one row. A sender’s delivery id is only unique within an endpoint, so --source-id on its own is refused. The PAYLOAD column is held or dropped, which is what decides whether crewship work replay can work on the item this delivery produced.

crewship work deliveries get <delivery-id>

Show one delivery: which endpoint and signature profile accepted it, what the filter decided and why, the work it produced, and whether its payload is still held.
The payload itself is never printed. body_sha256 and the byte count identify it without publishing whatever the sender put inside.

crewship work resolve <work-id>

An operator can settle needs_reconciliation after inspecting the runtime and its external effects. Stop any surviving runtime first. Read the current generation with work get, then record the observed outcome:
Allowed outcomes are succeeded, failed, and cancelled. The command requires manager permissions, a reason, the current generation, and explicit confirmation that the runtime is stopped. It records the operator and reason, releases the held ledger capacity, and rejects stale decisions. The confirmation is an operator attestation; this command does not stop or automatically inspect a container. Any subsequent rerun requires a separate, deliberate work replay. Routine webhook runs remain under the pipeline API and have no work-item controls.