The rex CLI

rex does not run your stack. It drives the running app — the same code paths the UI uses, reached over a private unix socket in rexenv’s config directory, permissions 0600.

That design has one consequence worth knowing before anything else: rexenv has to be open. There is no headless mode, no daemon to start from the terminal, and no second implementation of site creation living in the CLI that could drift from the app’s.

Getting it

Installed with Homebrew, rex is already on your PATH — the cask links it into Homebrew’s bin.

Installed from the disk image, Settings → install rex on PATH puts it there.

Check it:

rex --version

Tip

rex --version and rex -v are the only commands that work with the app closed. Everything else needs it running, and says so rather than hanging.

Exit codes

Worth wiring into scripts, because the third one is the interesting case:

Code	Meaning
0	The command succeeded
1	The command ran and failed
2	rexenv isn’t running

2 is separated from 1 deliberately: “your site could not be created” and “there was nobody to ask” are different problems, and a script that retries the first should give up on the second.

Machine-readable output

Every command takes --json and returns the raw response data:

rex --json site list | jq -r '.[] | select(.serving) | .domain'

Where to start

rex status          # what is running, and whether rexenv owns it
rex doctor          # what is wrong, and what to do about it
rex help            # the whole command surface

rex doctor is the one to reach for first when something is off — it checks DNS and resolver takeovers, the edge’s wire identity, port conflicts, and whether the CLI link itself is intact.

Shell completions are available for zsh and bash:

rex completions zsh > /opt/homebrew/share/zsh/site-functions/_rex

The full surface

CLI reference lists every command, ported from rex help itself.