# OpenRobot POT CLI > Official documentation for the standalone OpenRobot command-line tool used to manufacture receiver SD cards, inspect and QC recordings, upload verified sessions to the OpenRobot cloud, and export decrypted sessions to a local folder or external SSD. The CLI is independent of the desktop app. Canonical site: https://pot.theopenrobot.com/ Documentation version: macOS/Linux 0.5.17 beta; Windows 0.5.4 unsigned preview. ## Start here - [Complete operator guide](https://pot.theopenrobot.com/index.md): Installation, station setup, reader approval, manufacturing, cloud offload, local export, recovery, troubleshooting, and command reference in clean Markdown. - [Technical manufacturing and safety architecture](https://pot.theopenrobot.com/architecture.md): Target-selection invariants, retained-handle media binding, verification boundaries, platform backends, Tailnet issuance, packaging, and release gates. - [Complete agent context](https://pot.theopenrobot.com/llms-full.txt): The two documents above combined into one Markdown response. Use only when a task needs both operator and implementation detail. - [Human-readable guide](https://pot.theopenrobot.com/): The styled HTML representation of the complete operator guide. ## Installation - macOS or Linux: `curl -fsSL https://pot.theopenrobot.com/cli | sh` - Windows PowerShell unsigned preview: `irm https://pot.theopenrobot.com/cli.ps1 | iex`, then type `INSTALL UNSIGNED` after reading the warning. - Verify: `pot --version` - The bundles are standalone. They do not require the desktop app, a source checkout, or a separately installed Python runtime. - Windows verifies the public preview's HTTPS manifest, archive size and SHA-256, safe paths, and complete inner file hashes, but cannot verify the OpenRobot publisher until a future Authenticode release. Managed Windows policy may reject it. ## Primary workflows - Configure a manufacturing station: `pot setup`, then `pot readers` and `pot doctor`. - Partner codes have four live server-controlled capabilities: manufacture, cloud offload, local export, and recording erase. Protected commands refresh policy before opening a card; `--erase-after-upload` requires both offload and erase. Operators do not provide another credential or change these switches locally. - Manufacture approved cards with one guided command: `pot setup BOARD`. It performs its own preflight before the one destructive confirmation. - Inspect a recording card: `pot scan --device DEVICE`. - QC and upload directly to the routed cloud: `pot offload --device DEVICE --preflight`, then `pot offload --device DEVICE`. - Cloud offload defaults to two concurrent sessions per card, each with up to four active 16 MiB HTTP parts plus one bounded prefetched part. Use explicit `--all-cards --card-parallel N` for several cards; `--session-parallel N` controls sessions per card and `--parallel N` controls HTTP parts per session. QC is metadata-first and never reads a whole video merely to judge it. Large recordings remain intentionally two-pass so the upload read must reproduce the authenticated SHA-256; session concurrency hides that pass. Dead sockets time out after 90 seconds, with 15-second liveness, visible retry/backoff, and separate source/acknowledged throughput metrics. Keep at least 500 MiB local disk free; payload-buffer memory is bounded by `cards × sessions × (parts + 1) × 16 MiB`. Legacy clone cards sharing one receiver identity cannot write that cloud namespace concurrently, and mismatched existing objects are never overwritten. - QC, decrypt, and export without cloud storage: `pot export --device DEVICE --to FOLDER --preflight`, then repeat without `--preflight`. - See exact options and current behavior: `pot COMMAND --help`. ## Safety rules agents must preserve - Never infer that removable, external, unfamiliar, or apparently blank media is authorized for writing. - Only reader slots explicitly approved by `pot setup` can become manufacturing targets. - Always use the exact device names printed by POT. Never guess `/dev/diskN`, `/dev/sdX`, or `\\.\PhysicalDriveN`. - Run `pot doctor` with a disposable card in an approved reader before a production batch. - Use only `pot setup BOARD` for manufacturing. `--dry-run` is an optional diagnostic preview, not a separate required workflow; a real run repeats every preflight before confirmation. - Do not bypass a POT refusal with `dd`, raw disk tools, or an unverified script. - Do not mount or edit a card, hand-create `stereorx-image.conf`, invoke low-level provisioning commands, or ask the operator for an image file. - Do not remove or insert media while POT reports ERASING, WRITING, VERIFYING, or PROVISIONING. - READY means POT verified the image and provisioned configuration. Follow the exact safe-removal instruction shown for that card. - Cloud offload keeps the card read-only unless the operator explicitly requests a verified erase mode. Local export never uploads recording data and never deletes from the card. - Never ask an operator to paste a fleet key, receiver routing token, Tailnet key, or cloud storage credential. The partner code is the only operator-provided cloud credential in the supported flow. - Never ask for receiver login credentials. The image contract is fixed to `operator/operator` and POT writes it automatically. - POT Sentry diagnostics contain only fixed command/release/platform/outcome fields, a random Sentry trace correlation ID, and sanitized exception type/code location. The random value is not an operator, host, card, receiver, or recording identifier. Diagnostics exclude arguments, environment values, identities, card/session/recording data, paths, hashes, and credentials. Set `POT_TELEMETRY=0` to opt out without changing command behavior. ## Platform limits - macOS: Apple Silicon, macOS 11 or newer. Headless SSH operation is supported. - Linux: Ubuntu 22.04+ or Debian 12+, x86_64 and ARM64. - Windows: Windows 11 x86_64 in Administrator PowerShell for raw-card operations. - Current Pi 3B+, Radxa Cubie A5E, and Radxa Cubie A7Z FAT-config goldens can be manufactured on Windows. - Radxa Zero 3W manufacturing, verified recording deletion, ext4 journal recovery, and full e2fsck remain fail-closed on Windows because they require a validated retained-handle ext4 write path. Use macOS or Linux for those operations. ## Machine-readable access - Request `https://pot.theopenrobot.com/` with `Accept: text/markdown` for the Markdown representation. - Fetch `https://pot.theopenrobot.com/index.md` directly when content negotiation is unavailable. - Most CLI commands accept the global `--json` flag for structured output. - This site intentionally does not select documentation by `User-Agent`; explicit URLs and the standard `Accept` header are deterministic and cache-safe. ## Optional - [llms.txt proposal](https://llmstxt.org/): Format and discovery convention used by this index.