EFEnvForgeJoin waitlist

Docs / Service command history

Workspace command history is safe to paste into handoffs.

Use envforge workspace commands [workspace] --service <service>to review recent service command receipts for a branch workspace. The output is intentionally metadata-only: it can be filtered by status, limited for readability, or emitted as JSON without printing payloads, results, or error text.

Review workspace lifecycleReview safe outputs
workspace commandsservice history

$envforge workspace commands signed-links --service api --status failed --limit 5

workspace: signed-links; service: api

filter: status failed; limit 5

visible: command receipt metadata

hidden: payloads, results, error text

Command execution

Run setup and test commands through the service runtime boundary.

From the CLI or dashboard, choose a workspace service and request a setup or test command. EnvForge turns that request into a queued runtime command, captures logs and result state, then shows the evidence with declared secrets masked.

Choose the serviceCLI or dashboard

Run a setup or test command against one workspace service instead of opening an unscoped runtime session.

Queue runtime workruntime command

EnvForge queues the request for that service, wakes the runtime when needed, and records who asked for the command.

Capture evidencelogs + result

Command logs, exit status, timing, and result state stay attached to the command receipt for later CLI and dashboard review.

Redact secretsmasked output

Secret values are redacted before logs, results, or receipts are shown in the CLI, dashboard, or handoff text.

Command history boundary

Query the service history without turning it into a log dump.

Command history should answer which service command ran and how it ended. It should not become another place where request payloads, result bodies, or provider error text escape into handoffs.

Service scoped--service <service>

Start from the workspace and service that ran the command so the history stays tied to the runtime surface someone is debugging.

Status filtered--status <status>

Narrow the list to the status you need before pasting the receipt into an issue, PR, or agent handoff.

Small by default--limit <n>

Keep command history short enough for review notes and support threads without dumping a full workspace timeline.

Automation safe--json

Use JSON for scripts and agents. The structured output follows the same safety boundary as the terminal view.

Failed command handoff

A failed command should leave a pointer, not a payload.

When a setup, smoke, or service command fails, the safe artifact is a receipt that points authenticated operators to the evidence and names the next decision without publishing raw output.

command receiptfailure handoff

receipt: cmd_01HX8M4W; workspace: signed-links

service: api; command: smoke; status: failed; exit: 1

started: 16:04Z; finished: 16:05Z; runtime: Small

visible: metadata, timing, status, exit code

private: payload, raw output, exception detail, provider message

next: inspect authenticated logs before retry

  1. Receipt idcmd_01HX...

    Reference the command without pasting output.

    A failed-command handoff should name the receipt id, workspace, service, status, started time, finished time, and exit code.

  2. Next inspectionlogs behind auth

    Point operators to authenticated evidence.

    Use the receipt to find authenticated logs or result detail instead of copying raw exception detail, payloads, or provider messages into public review notes.

  3. Retry decisionretry / block / escalate

    Make the next action explicit.

    The handoff should say whether the command is safe to retry, blocked on resource readiness, or needs a human owner before another runtime wake.

  4. Cost noteruntime may wake

    Call out billing before reruns.

    Retrying a service command can wake the runtime, so command handoffs should include the selected size and cap posture when the run is not trivial.

Review checklist

A command-history handoff is safe when it explains state, not contents.

Treat command history as an operator receipt. It should help humans and agents decide what to retry or inspect next while leaving raw command data behind authenticated logs and runtime access.

Showreceipt metadata

Workspace, service, status, timing, and command receipt metadata are safe for handoffs.

Reviewers can see what ran and whether it completed.
Hidepayload / result / error text

The command history view does not print command payloads, result bodies, or raw error text.

Failures stay diagnosable without leaking request data or logs.
Sharefiltered history

Use status and limit filters before sharing command history outside the operator context.

Handoffs stay focused on the service state someone can act on.