Explicit instance
login-web names the NexusClaw instance instead of relying on an ambiguous target.
← All capabilities
Developers / Governed DX
Turn digital-workforce delivery intoa comparable, automatable, rollback-ready engineering workflow
NexusClaw CLI brings organization login, target resolution, source sync, workforce training, release, and observation into the terminal while preserving platform permissions, workspace isolation, audit, and Release Gate.
It is not an administrative backdoor around the product control plane. Every remote write uses controlled APIs; target mismatch, source conflict, insufficient access, or missing release evidence fails explicitly.
nexus · verified CLI build 0.3.49
$npm install --global @nexusclawhq/cli
$nexus --build-info
@nexusclawhq/cli@0.3.49
gitSha: 11603b509395ad0a...
contentDigest: sha256:8b5928b29232...
$nexus org login-web --instance-url <instance-url> --alias dev
OAuth 2.1 · PKCE S256 · machine-local credential
$nexus workspace current --target-org dev --json
one target resolved before network mutation
01 / Identity & Target Context
Each machine authenticates independently; each command resolves exactly one target
Browser login uses OAuth 2.1 PKCE. Credentials are encrypted on the machine and never enter the project repository. Only non-secret environment descriptors and workspace bindings are shared. Remote commands verify org alias, instance URL, and workspace UUID before sending a request.
One TargetContext
Flags, environment descriptor, manifest, and org credential converge on one target.
No credential copying
Machine A and B authenticate separately; Git carries the project and revision evidence.
Fail before request
Missing or inconsistent bindings stop before network access.
Developer machine
encrypted credential
OAuth 2.1 + PKCE
browser callback
Org alias dev
instance + identity
TargetContext
single resolution
Workspace UUID
remote isolation boundary
Machine A
nexus org login-web --alias dev
~/.nexusclaw/auth/dev.json
Machine B
nexus org login-web --alias dev
independent credential · same project
02 / Source & Revision Workflow
See drift and conflicts before choosing a read or write
The YAML manifest is canonical and JSON is a validated generated projection. Source Tracking compares local, remote, and baseline. Pull and push support dry-run and path selection; conflicts block by default.
Validate
Check manifest, environment descriptors, and local package contracts.
Status
Separate local, remote, drift, and conflict states.
Diff
Compare runtime, source, package, or composer.
Dry run
Produce a plan without changing baselines or remote state.
Apply
Write selected paths and record before / after revision.
Rollback
Use deployment history or package versions through existing audit paths.
source-inspection.sh
$nexus validate --json
manifest · environments · package contracts / checked
$nexus source status --drift
Local Changed nexus-app/objects/account.yaml
Remote Changed nexus-app/pages/account-list.yaml
$nexus diff --mode source --target-org dev
local ↔ baseline ↔ remote
controlled-write.sh
$nexus source pull --dry-run --path nexus-app/pages
plan only · no local files or baseline written
$nexus workspace push --dry-run --json
phase: dry-run · remote state unchanged
$nexus deployment rollback --history-id <id> --json
revision-ledger entry recorded
03 / Workforce Lifecycle
Train, evaluate, publish, and observe from one terminal without creating a second write path
Workforce commands are thin authenticated clients. Learning candidates still pass simulation, approval, and Release Gate. Provider configuration and workforce promote, rollback, and revoke require short-lived MFA step-up.
Honest CLI boundary
Role skills currently expose a read-only directory, so fake create/update/delete verbs are absent. Knowledge distillation has no on-demand mutation, so there is no workforce distill run. When the backend contract does not exist, the CLI does not pretend it does.
01 · Signal
Extract a learning signal from real execution.
02 · Draft
Generate and apply an explicit asset candidate.
03 · Simulate
Run tests and pre-release evidence.
04 · Approve
Route the release decision to an authorized person.
05 · Publish / roll back
Use registered owners and paired rollback paths.
workforce-governance.sh
$nexus workforce learning extract --execution-id <id> --target-org dev
$nexus workforce learning draft generate --candidate-id <cid> --target-org dev
$nexus workforce learning simulate --candidate-id <cid> --target-org dev
$nexus workforce learning request-approval --candidate-id <cid> --target-org dev
$nexus workforce learning publish --candidate-id <cid> --target-org dev
Release Gate → registered publication owner → audit evidence
$nexus workforce observe audit chain --target-org dev
04 / Automation & Evidence
Human terminal output and CI automation share the same command contract
Supported commands emit one `nexusclaw.cli-result/v1` document with `--json`: stable exit code, command, phase, data, diagnostics, evidence, and next commands. Secret fields, tokens, stacks, and raw provider responses are centrally scrubbed.
Build identity
Query package version, Git SHA, and content digest directly.
Deterministic diagnostics
Sort by file, JSON path, rule, and code.
One-document output
JSON mode contains no spinner, color, banner, or prose.
Revision evidence
beforeRevision, afterRevision, history, and rollback results form a continuous ledger.
nexus-command-result.json
{
"schemaVersion": "nexusclaw.cli-result/v1",
"ok": true,
"exitCode": 0,
"command": "workspace push",
"phase": "dry-run",
"data": { ... },
"diagnostics": [],
"evidence": [],
"nextCommands": []
}
Cross-machine work shares the project, not identity
Two machines read the same manifest, environment descriptors, and revision ledger from Git while holding independent org sessions. If the server revision advances, an older machine fails push instead of overwriting newer work.
Machine A
own login · revision 18
Git
⇄
⇄
Machine B
own login · revision 19
revision 18 push → conflict / fail closed
Customer Evaluation Checklist
Validate both the success path and the refusal path
01
Clean-machine login
Install the CLI, complete PKCE login, and resolve exactly one workspace.
02
Conflict and dry-run
Create remote drift, then confirm visible status, blocked push, and no dry-run write.
03
Release Gate
Remove approval or evidence and confirm publish returns the real blocker.
04
Machine output
Confirm one JSON document, stable exit code, and no token or secret field.
Current capability boundary
The CLI requires Node.js 18+ and a reachable NexusClaw instance. It does not replace Git, CI, or platform permissions, and it does not wrap unimplemented backend capabilities as commands. Public examples use placeholder instances and workspaces with no real credentials.
Bring one real development-to-release workflow
We will start from a clean-machine login and walk through target binding, diff, dry-run, controlled write, Release Gate, machine output, and rollback evidence.