CLI reference
Configure Pix hosts, workspaces, devices, sessions, services, and diagnostics from the command line.
Run pix --help or pix <command> --help for the flags shipped by your
version. The global --config <path> option (or PIX_CONFIG) selects an
explicit configuration file for every command.
Without an override, Pix stores host configuration at
$HOME/.config/pix/config.json on macOS and Linux. pix status prints the
resolved path; host identity, service state, and logs live in the same Pix
configuration directory.
Two modes: interactive and headless
The same binary serves humans in a terminal and scripts or agents on a machine contract.
Interactive mode is the default in a TTY:
- A bare
pixopens the home screen: a read-only host snapshot on top and an action menu below. It never creates or modifies configuration. - A group command without an action (for example
pix deviceorpix workspace) opens that group's menu. Actions that remove trust — revoking a device, removing a workspace — ask for confirmation first.
Headless mode is opt-in with two global flags:
pix --output json --no-input status--output human|json(orPIX_OUTPUT) selects the format. JSON mode never prompts and never opens a menu.--no-inputmakes any command that would otherwise wait for a selection fail with a usage error instead; pass the required ID explicitly.
Outside a TTY, a bare pix prints the standard help text and exits 0, so
pipelines and schedulers never block on a menu.
The JSON envelope
Every JSON-mode command prints one object. Success goes to stdout, errors to stderr:
{"schema_version": 1, "ok": true, "command": "status", "data": { ... }}
{"schema_version": 1, "ok": false, "error": {"code": "usage", "message": "..."}}Exit codes: 0 on success, 2 for usage errors (missing arguments or a
required ID), 1 for command failures. Human-readable text is not a
contract; parse only this envelope. An agent-facing skill with the full
command inventory lives in skills/pix-cli/SKILL.md.
Setup and diagnostics
pix setup
pix status
pix logs --tail 50pix setup is the product-facing first-use flow. It checks Pi, authorizes a
workspace, offers LAN or relay access, guides pairing, and installs the
per-user host service. Useful setup options include:
pix setup --workspace "$HOME/Projects/my-project"
pix setup --relay wss://relay.example.com
pix setup --no-pair --no-service --non-interactive \
--workspace "$HOME/Projects/my-project"
pix setup --advancedInteractive setup goes straight to the recommended path; --advanced
exposes host name, Pi selection, connectivity, workspaces, and the
service question with a review step. Pairing is optional during setup
(pix device pair works any time), and abandoning the wizard before it
commits leaves no config file behind.
pix status prints configuration, host-service state, and the resolved Pi
executable with its version. pix logs prints payload-free host log entries;
use pix service logs for the same log through the service subcommand.
pix update upgrades the running executable (and the macOS app bundle) from
the repository's latest GitHub release, mirroring the first-party installer.
On a configured host, pix setup runs a health verification directly; relay
settings live in pix relay (the home screen's Settings entry).
Workspaces
Pix never browses arbitrary paths. Add a canonical folder before a client can use it:
pix workspace add "$HOME/Projects/my-project" --name my-project
pix workspace list
pix workspace sessions <workspace-id>
pix workspace remove <workspace-id>Full paths are printed only on the host. Removing a workspace revokes client access to that root; it does not delete files.
Devices
Pairing shows a confirmation code that a human should check against the
phone. In a terminal, pix device pair walks you through it; headless
callers split the flow into offer, review, and decision:
pix device pair # interactive: offer plus approval prompts
pix device pair --remote # interactive: relay offer with a QR code
pix device list
pix device pending # requests waiting for approval
pix device approve --code 123456
pix device reject --request <request-id>
pix device revoke <device-id>approve and reject accept exactly one of --request (the stable ID
from pix device pending) or --code (the six digits shown on the
phone). Revoking a device while the host service runs also closes its
live connections.
When a relay endpoint is active, pix device pair --remote starts a
short-lived remote pairing channel and prints a QR code. Without a relay
the host waits for a nearby client discovered over the local network.
Sessions
The host service owns the Pi runtimes it starts. Inspect and release them without stopping the service:
pix session list
pix session release <session-id>Releasing a runtime lets another Pi process resume that session file.
Pi selection
Pi is discovered from the host environment by default:
pix pi show
pix pi set /absolute/path/to/pi
pix pi clearUse pix pi set when a version manager or multiple installations make the
desired executable different from the one found on PATH.
Relay
Relay configuration accepts ws:// or wss:// endpoints:
pix relay set wss://relay.example.com
pix relay show
pix relay disable
pix relay enable
pix relay clearSetting a URL enables relay transport. disable keeps the endpoint but stops
using it; clear removes the stored endpoint.
Services
Pix uses one persistent host service so the menu-bar app and CLI share pairing, Bonjour, and transport state:
pix service install
pix service install --no-start
pix service install --adopt # explicitly switch the registered CLI owner
pix service start
pix service status
pix service restart
pix service stop
pix service logs --tail 100
pix service uninstallThe service is per-user: systemd user units on Linux and LaunchAgents on macOS.
pix serve remains available for a foreground host during development or
automation:
pix serve
pix serve --json-eventsThe JSON event stream is the native UI and automation bridge. It contains payload-free lifecycle and session events, not relay secrets or Pi messages.
The macOS App bundle is the canonical CLI distribution, and the Homebrew
pix command points to that same embedded binary. service start, status,
restart, and stop operate on the currently installed owner. Installing
from another CLI refuses to replace it; use service install --adopt only
when intentionally transferring ownership.
Diagnostics
Create a privacy-scrubbed bundle when reporting a problem:
pix diagnostics export ./diagnosticsReview the archive before sharing it. Logs and diagnostic bundles redact prompts, files, model output, credentials, private keys, pairing tokens, workspace paths, and relay secrets.