AI Workbench Command Line Interface (CLI) Reference
Overview
Run nvwb <command> --help for the full syntax and flags of any command.
The built-in help is the authoritative reference for command syntax, required arguments and available options.
This page covers what --help cannot: how commands are organized, behavioral notes, output formats and internal commands.
The CLI provides the same capabilities as the Desktop App.
You can manage locations, projects, environments, applications and git operations from a terminal. See Using the CLI for how-to guides on interactive use, scripting and agent integration.
The nvwb command is a shell wrapper around the nvwb-cli binary.
The binary lives at ~/.nvwb/bin/nvwb-cli.
The wrapper is a bash function defined in ~/.local/share/nvwb/nvwb-wrapper.sh and sourced into your shell through .bashrc.
It handles four session-state commands (activate, deactivate, open, close) by eval-ing the binary’s output to set environment variables in your live shell.
All other commands pass straight through to the binary.
The shell wrapper is only available in interactive shells that have sourced .bashrc.
Call ~/.nvwb/bin/nvwb-cli directly in scripts and agent tools.
See Using the CLI Binary for Scripts and Agents for the full calling convention.
Command Index
Use nvwb <command> --help for full syntax and options.
The tables below organize every command by category.
Context Management
Project Workflow
Git Operations
Compose (Docker / Podman)
The compose commands are only supported if you are using Docker, not Podman, as your container runtime.
Listing Resources
Creating Resources
Updating Resources
Deleting Resources
Configuring Resources
Package Management
Editing Files
Validation
Integrations
Installation
Support and Diagnostics
Shell Completion
Global Options
These options are available on every command.
Output Formats
The CLI does not change its output format when piped.
TTY and non-TTY output are identical — same table format and styling regardless.
Use -o json for any command whose output you want to parse.
JSON responses follow one of four shapes.
{"result": [...]}— List and query commands. Access items with.result[]injq.{"result": {...}}— Singular commands likestatus. Access fields with.result.FieldName.{"messages": [...]}—create projectandclone projecton success. The project path is embedded in the message string, not a dedicated field.{"error": "...", "detail": "..."}— All failures, all commands. Exit code 1.
Exit codes are meaningful.
Exit code 0 means success. Exit code 1 means error.
Behavioral Notes
This section covers behaviors that --help does not explain.
Use the Project Path, Not the Name
The registered project name comes from spec.yaml inside the repository, not from the directory name.
Cloning a project into --projectPath .../my-dir may register it under a completely different name.
Always use absolute paths with -p for scripting.
The name is for display; the path is stable and unambiguous.
Project State Machine
Many commands fail if the project is in the wrong state.
Check status -o json before running commands that have preconditions.
Build states (result.Environment.BuildState):
NO_BUILD— Build has never run or was reset.BUILDING— Build is in progress.BUILD_COMPLETE— Built and the project container is available.BUILD_ERROR— Last build failed.
Run states (result.Environment.RunState):
CONTAINER_NOT_CREATED— The project container does not exist.RUNNING— The project container is running.STOPPED— The project container exists but is stopped.
Preconditions by operation:
Useful Status Fields
The status -o json command returns detailed project information.
Session State Commands
The activate, deactivate, open and close commands manage shell session state.
They use eval to set environment variables in your live shell session.
After you activate a context, (nvwb:<context>) appears in your prompt and all subsequent commands target that context.
After you open a project, commands like build and start target that project.
These commands are only meaningful in an interactive terminal.
In scripts and agent tools, each command runs in its own process with no shared session.
Use -c and -p instead.
See Using the CLI Binary for Scripts and Agents for the scripting calling convention.
Stdin Value Ingestion
Some commands accept - as a value to read from stdin.
create environment-variable <name> -— reads the value from stdinupdate environment-variable <name> -— reads the value from stdinconnect integration <name> -— reads the token from stdin
Compose Notes
Compose commands require Docker as the container runtime.
They are not supported with Podman.
Compose file search order (relative to project root):
compose.yaml, compose.yml, docker-compose.yml, docker-compose.yaml,
deploy/compose.yaml, deploy/compose.yml, deploy/docker-compose.yml, deploy/docker-compose.yaml
Shell Completion
Generate autocompletion scripts with nvwb completion <shell>.
Supported shells: bash, zsh, fish, powershell.
All variants support --no-descriptions to omit completion descriptions.
Internal Commands
These commands are intended for power users, tooling integrations and the Desktop App GUI.
They are not shown in the main --help output.
Run nvwb internal <subcommand> --help for syntax and options.
Build Assistant
The build assistant analyzes failed container builds and proposes fixes using an AI inference backend.
See How to Use the AI Workbench Build Assistant for the full how-to guide.
Context Lifecycle
Container Lifecycle
Git Author Configuration
Shell and UI Helpers
System and Migration
Reference Labels
The following labels are preserved for cross-reference compatibility.
They point to the relevant section in this page or to the command index above.
Run nvwb <command> --help for complete syntax.
Related Topics
- Using the CLI - How to use the CLI (interactive, scripting, agents)
- Basic Quickstart (CLI) - CLI quickstart tutorial
- Release Notes - CLI version history