CLI reference

Alpha capability

The CLI currently operates on workspace environments that you have authorized through the browser. Account-wide administration and live observation tailing are not included in this alpha.

The seamward command gives developers one entry point for authorization, project setup, diagnostics, and read-only inspection of the active workspace environment.

Install

Install the command once. Installation does not open a browser, create a configuration directory, or modify the current project.

Code example

npm install -g @seamward/cli@alpha

Confirm the installed command:

Code example

seamward --versionseamward --help

Authorize and sign out

Code example

seamward loginseamward whoamiseamward logout

login prints the authorization URL and waits for Enter before opening the browser. Select a workspace, approve access, and wait for the Seamward success screen. The browser stays on Seamward while the CLI polls for the approved device grant and continues automatically. No local callback page is opened in the browser.

Login defaults to Sandbox. Use seamward login --live to authorize Live. Normal login does not grant deletion. Use seamward login --allow-delete only for a reviewed Integration deletion. Every configured connection must belong to that selected one-mode grant; use the workspace-key API to remove a workflow with both modes configured.

The authorization and active selection are stored outside the repository with owner-only file permissions. logout removes the Sandbox authorization by default. Use logout --live to remove another environment without signing out the others. To invalidate already issued access and refresh tokens, revoke the Project setup client in Workspace settings > MCP.

Set up a project

Run setup from one deployable backend service directory:

Code example

seamward setup

The command uses the Sandbox authorization unless an exact environment flag is supplied, previews the exact project files it would add or change, and installs project-scoped MCP configuration only after approval. It never reads or edits an environment file. Continue in the coding agent with one of the suggested prompts: set up, review only, check status, or review local credential saving. See Choose your next prompt. These requests do not bypass setup, runtime, or credential-saving approvals.

Finish local runtime setup

After the agent connects the Sandbox integrations, run:

Code example

seamward setup credentials

This interactive command selects a supported local environment destination, shows key names and conflicts without values, and asks before saving. No startup script or package.json is required. After saving, the CLI checks each saved Connection key and ingest token with Seamward. Exit 0 means every connection passed; a failed check exits 1 and leaves the saved file intact. This check does not start your app or send observations. No native agent dialog is involved. To check the selected file again:

Code example

seamward setup verify

CONNECTION VERIFIED describes this invocation only. It does not prove your app loads the file or emits observations. Start your app normally with that file loaded and check for real observations in Seamward. Read-only status commands are:

Code example

seamward setup --statusseamward setup --status --json

The credentials, verify and verify-app commands require Sandbox or an exact legacy Development grant and an interactive terminal; --yes, environment flags and JSON mutation are refused. --status is read-only and exits 0 only when local setup is current and every required Integration has an active (or not-applicable) contract and an accepted observation. Waiting, stale and incomplete states exit 1. Optional application testing is not required. Observed traffic is not proof of deployment or ongoing health; startup-test status remains separate.

File saving supports macOS/Linux and root .env and .env.local, independently of framework loaders. See local saving for safe recovery.

Explicit application diagnostic

This is not part of normal onboarding. Use it only when you specifically want an automated smoke test and already have reviewed startup and synthetic traffic scripts:

Code example

seamward setup verify-app

It requires a supported explicit Node --env-file loader. You select the startup script, readiness URL and traffic mapping, review their effects, and approve execution. It does not infer how arbitrary applications start. It stops its own processes after checking fresh observations and does not write credentials. Each retry needs a fresh review. Normal application observations do not require this test.

Setup never opens a browser. If the active authorization is missing, expired, or revoked, it exits before changing the project and instructs you to run seamward login, then rerun setup.

Use the automatic setup guide for the complete source review, remote approval, contract, runtime credential, and first-observation workflow.

After Sandbox source setup is verified, promote it without changing source:

Code example

seamward login --liveseamward setup --liveseamward deployment env --live

The promotion command previews remote Integration and contract effects, then applies them after confirmation. It never applies local source setup. Store the explicit deployment output in the hosting platform's secret manager and deploy the same source revision. There is no SEAMWARD_ENVIRONMENT variable.

Select a locally authorized context

Code example

seamward workspaces listseamward workspaces use <slug>seamward environments list

These commands list browser-authorized contexts already stored on this device. Authorize another workspace environment with the corresponding login flag. Commands always default to Sandbox. Add --live to the individual command to select Live. A previously selected Live authorization does not change that default.

Legacy workspaces

Until your workspace is migrated, use --development, --production, or --staging to select its exact stored environment. These flags do not provision another environment or grant access to a different object. Canonical workspaces use the default Sandbox and explicit --live. Conflicting flags fail before any network request or local write. Removal dates for legacy flags remain pending the migration release.

Inspect Integrations

Code example

seamward integrations listseamward integrations show <integration-id>seamward integrations delete <integration-id>

The commands are scoped to the active workspace environment. List and show are read-only. The list prints the stable wint_... Integration ID and the selected environment's int_... connection ID. Show and delete take the stable Integration ID. Delete creates a current impact preview across every environment connection, requires an interactive exact-name confirmation, and then permanently removes the Integration and its owned Seamward operational data. It rejects --yes, --force, piped input, and unattended execution.

Inspect observations and contracts

Code example

seamward observations list --integration <integration-id>seamward observations list --integration <integration-id> --limit 25 --cursor <next-cursor>seamward observations show <observation-id> --integration <integration-id>seamward contracts list --integration <integration-id>seamward contracts list --integration <integration-id> --limit 25 --cursor <next-cursor>seamward contracts status --integration <integration-id>seamward contracts validate <file>

Observation and contract reads use the active setup authorization and remain limited to its approved workspace environment. Their --integration argument is the selected environment's int_... connection ID printed by seamward integrations list. Contract validation reads only the named project file, validates OpenAPI 3.0/3.1 or JSON Schema draft 7/2020-12, and rejects paths outside the current project. List responses include nextCursor; pass it back unchanged to continue.

Diagnose the active connection

Code example

seamward statusseamward doctor

status reports the active workspace, environment, and Integration count. doctor performs the same authenticated context check and reports the local Node.js version.

Command options

CommandOptionsConstraint
login--live, --development, --production, --staging, --allow-delete, --console-url <url>, --api-url <url>Defaults to Sandbox. Live and legacy targets are explicit. Destructive scope requires --allow-delete.
setup--live, --development, --production, --staging, --dry-run, --yes, --integration <id>, --disconnectSandbox and exact legacy Development install the local MCP. Live and legacy Production/Staging perform remote-only promotion.
workspaces use<slug>The workspace must already be authorized locally.
deployment env--live, --development, --production, --stagingPrints sensitive runtime values only after explicit invocation. Send the output to a secret manager and never commit it.
integrations show<integration-id>The Integration must belong to the active environment.
integrations delete<integration-id>Requires a current preview, an interactive terminal, and the exact Integration name. Existing authorizations may require seamward login again for delete scope.
observations list--integration <id>, --limit <number>, --cursor <cursor>, --json--integration is required. --limit accepts 1 to 100 and defaults to 25. Pass nextCursor back unchanged.
observations show<observation-id>, --integration <id>, --json--integration is required and is enforced by the API.
contracts list--integration <id>, --limit <number>, --cursor <cursor>, --json--integration is required. --limit accepts 1 to 100 and defaults to 25. Pass nextCursor back unchanged.
contracts status--integration <id>, --json--integration is required.
contracts validate<file>, --jsonThe file must stay inside the current project and use a supported OpenAPI or JSON Schema version.
Read and diagnostic commands--live, --development, --production, --staging, --jsonCommands default to Sandbox. Unsupported, conflicting, or duplicate options fail before local or remote work begins.

Machine-readable output

Add --json to customer commands when their output is consumed by a script:

Code example

seamward whoami --jsonseamward integrations list --jsonseamward status --json

Successful JSON output is the same response object returned by Seamward. For example, an observation page includes observations, nextCursor, and pagination. A local validation returns:

Code example

{  "file": "contracts/orders.openapi.yaml",  "format": "openapi",  "valid": true}

Command failures exit with status 1. With --json, stderr contains:

Code example

{  "error": {    "code": "usage_error",    "message": "Actionable error message."  }}

Stable error codes include usage_error, authentication_required, validation_failed, scope_denied, not_found, network_error, request_failed, and command_failed. Invalid command syntax exits non-zero without changing local or remote state.

Authentication failures exit non-zero and direct the operator to seamward login. Unknown commands and missing required arguments also exit non-zero without changing local or remote state.

Advanced project commands

The command retains lower-level, review-first project operations for custom automation:

Code example

seamward discover .seamward project plan .seamward review .seamward verify .

These commands are read-only unless their help explicitly documents a write flag. Prefer seamward setup for the supported customer onboarding flow. The assisted setup command runs the exact setup engine version pinned by the installed CLI. Do not use the former seamward setup [directory] planner syntax; use seamward project plan [directory] for that advanced flow.

Next: follow Automatic setup, or resolve a failure with the Error reference.