> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pipecat.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Output Modes and Exit Codes

> Render pipecat cloud output as rich, plain, or json, read its exit codes, and run it non-interactively in CI.

Every `pipecat cloud` command shares one output contract and one set of exit codes. Both matter most in CI, where there's no terminal to read and the exit status is the only signal your pipeline gets.

## Output modes

`--output` is a global option, so it goes before the subcommand:

```bash theme={null}
pipecat cloud --output json agent list
```

| Mode    | What you get                                                                                                                                                                     |
| ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `rich`  | Panels, spinners, and tables. The default on a terminal.                                                                                                                         |
| `plain` | Line-oriented: no boxes, no spinners, no truncation. The default when output is piped or redirected. Listings are tab-separated, and long values are never wrapped or shortened. |
| `json`  | One machine-parseable JSON object on stdout.                                                                                                                                     |

In `json` mode, stdout carries nothing but the JSON payload — every
human-facing message, including errors and progress, moves to stderr. That
means you can pipe stdout straight into a parser without filtering:

```bash theme={null}
pipecat cloud --output json agent list | jq -r '.agents[].name'
```

<Tip>
  Piping already gets you `plain`, so scripts that just need stable, untruncated
  text don't have to pass anything. Reach for `json` when you want to read
  specific fields.
</Tip>

### Setting it once

The mode resolves in this order, first match winning:

1. The `--output` flag
2. The `PIPECAT_OUTPUT` environment variable, or the `output` key in your CLI config file
3. Auto-detection: `rich` on a terminal, `plain` otherwise

So a CI job can set it once for every step:

```yaml theme={null}
env:
  PIPECAT_OUTPUT: json
```

An unrecognized mode is a usage error — the CLI names the valid modes and exits 2.

## Exit codes

| Code | Meaning                                                                                                                                                                                                         |
| ---- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `0`  | The command completed.                                                                                                                                                                                          |
| `1`  | The command ran and failed: an API error, a validation failure, a missing agent, or a confirmation you declined.                                                                                                |
| `2`  | The command was called wrong, or it needed to prompt and couldn't. Unknown flags, invalid option values, and an unrecognized `--output` mode land here, as does any prompt reached without a terminal on stdin. |

Declining a confirmation exits 1 rather than 0 — an aborted deploy is a failed
step, not a successful no-op.

## Running non-interactively

Rather than let a prompt hang or misread a closed stdin, a command that would
prompt checks for an interactive terminal first and exits 2 with the flag that
skips the prompt:

```
Confirmation required but input is not a terminal.
Pass --yes to run non-interactively.
```

This applies to every prompt, so the rule to script by is: if running a command
by hand asks you a question, the CI version of that command needs the
corresponding flag.

| Command                            | Flag                               |
| ---------------------------------- | ---------------------------------- |
| `deploy`                           | `--yes` (or `--force`, implies it) |
| `agent start` / `stop` / `delete`  | `--force`                          |
| `secrets set` / `unset` / `delete` | `--skip`                           |
| `secrets image-pull-secret`        | `--skip`                           |
| `docker build-push`                | `--yes`                            |
| `spend-limit set` / `clear`        | `--yes`                            |
| `organizations keys create`        | `--name`                           |

A few commands exist only to ask you something — `organizations select` and
`organizations keys use` present a picker and have nothing to bypass. Use
`--organization` on the individual command instead of selecting one first, and
set `PIPECAT_TOKEN` rather than authenticating interactively.

<Note>
  These flags skip the *prompt*, not the *check*. `agent delete --force` still
  refuses to delete an agent that doesn't exist, and `deploy --yes` still fails
  on an invalid config.
</Note>

## More Information

<CardGroup cols={2}>
  <Card title="Personal access tokens" icon="key" href="/pipecat-cloud/guides/personal-access-tokens">
    Authenticate a CI job with PIPECAT\_TOKEN
  </Card>

  <Card title="CI with GitHub Actions" icon="github" href="/pipecat-cloud/guides/ci-with-github-actions">
    A full deployment pipeline
  </Card>
</CardGroup>