postgresai 0.17.0-dev.0 → 0.17.0-dev.11

package/README.md

@@ -76,6 +76,8 @@ Password input options (in priority order):
 - `PGAI_MON_PASSWORD` environment variable
 - if not provided: a strong password is generated automatically
 
+Monitoring passwords must use printable ASCII characters; non-ASCII passwords are rejected until SASLprep normalization is supported. Role creation and password resets send a SCRAM-SHA-256 verifier instead of the cleartext password, including when the server uses `password_encryption=md5`. Printed SQL redacts the verifier as well. Server statement logging can still record the verifier; treat it as sensitive.
+
 By default, the generated password is printed **only in interactive (TTY) mode**. In non-interactive mode, you must either provide the password explicitly, or opt-in to printing it:
 - `--print-password` (dangerous in CI logs)
 
@@ -125,6 +127,52 @@ Notes:
 - All standard options work with Supabase mode (`--verify`, `--print-sql`, `--skip-optional-permissions`, etc.)
 - When using `--verify`, the tool checks if all required setup is in place
 
+### ClickHouse Managed Postgres
+
+Hosts ending in `.pg.clickhouse.cloud` are auto-detected; `--provider clickhouse` forces it.
+The plan is the same superuser plan as self-managed Postgres (`--print-sql` shows it).
+
+```bash
+npx postgresai prepare-db 'postgres://postgres:...@xxx.pg.clickhouse.cloud:5432/postgres?channel_binding=require'
+```
+
+Before any grant runs, one `-- scope:` line lists exactly what the run grants the
+monitoring role, derived from the steps about to run (so it shrinks under `--skip-optional-permissions`
+and is not printed on `--reset-password`, which grants nothing). With `--json` it goes to stderr.
+
+For `prepare-db`, `channel_binding=require` in a URI or conninfo string enables SCRAM-SHA-256-PLUS when the server
+offers it, disables the plaintext retry that `sslmode=prefer` would otherwise do, and is rejected
+together with `sslmode=disable`. The mechanism actually negotiated is not enforced by the driver.
+
+The collector cannot do channel binding. `mon targets add`, `mon local-install --db-url`, and
+`pgai connect` remove `channel_binding` from the saved/box URL. With `require`, they refuse
+`sslmode=disable` or `allow`; keep `verify-full` with a warning; and upgrade `require`, `prefer`,
+`verify-ca` or unset to `verify-full` after testing certificate and hostname verification with
+Node's default trust store (or the CA file in `sslrootcert`). Authentication or other errors after
+a verified TLS handshake do not block the upgrade. If verification fails, provide
+`sslrootcert=<CA file>` with `sslmode=verify-full`, or explicitly accept the downgrade by removing
+`channel_binding=require`. Successful upgrades print the collector warning and
+`upgraded to sslmode=verify-full`. `channel_binding=prefer` or `disable` is removed with a note.
+
+### ClickHouse Cloud host metrics
+
+For a ClickHouse Managed Postgres target, `mon local-install --db-url` and `mon targets add` also set up
+host metrics (CPU, memory, disk, I/O) from the ClickHouse Cloud Prometheus endpoint when these are set:
+
+```bash
+export CLICKHOUSE_ORG_ID='<org-id>' CLICKHOUSE_KEY_ID='<key-id>' CLICKHOUSE_KEY_SECRET='<key-secret>'
+npx postgresai mon local-install --db-url 'postgres://postgres_ai_mon:...@xxx.pg.clickhouse.cloud:5432/postgres?sslmode=require'
+```
+
+Use an organization API key with the **Basic Service API Reader** role: it is the least privilege that
+works (it can list Postgres services and read `/prometheus`, and cannot change anything or create keys).
+The CLI does not need an Admin key.
+
+The key secret is stored in plaintext in `host-metrics/clickhouse-<name>.secret` in the monitoring
+project directory (file 0600, directory 0700), because VictoriaMetrics reads it from a file for basic
+auth. It is never printed or logged. `mon targets remove <name>` deletes it. To rotate the key, re-run
+`mon targets add` with the new key.
+
 ### Verify and password reset
 
 Verify that everything is configured as expected (no changes):
@@ -141,6 +189,144 @@ npx postgresai prepare-db postgresql://admin@host:5432/dbname --reset-password -
 
 ## Quick start
 
+### One command: `pgai connect`
+
+```bash
+pgai connect 'postgresql://postgres:<password>@<host>:5432/postgres'
+```
+
+It signs you in if needed, creates the `postgres_ai_mon` role (with an admin URL; otherwise it
+prints the SQL), provisions monitoring in PostgresAI Cloud, runs the express checkup (the checks
+of `pgai checkup`, as `postgres_ai_mon`) while the box starts and prints its findings (in JSON:
+`checkup`; skipped where PostgresAI keeps the role's password: no `checkup` key, no first report),
+waits, and prints the dashboard URL. Safe to re-run; a `--clickhouse-key` given on a
+re-run is checked, and a rejected one is `action_required`. For ClickHouse Managed Postgres add `--clickhouse-key <key-id>:<key-secret>`
+(a Basic Service API Reader key) for CPU, memory and disk. `--self-hosted` runs the stack on this
+machine instead. When stdout is not a terminal the result is JSON with `status`, `dashboard_url`
+and `next`. Then: `pgai databases`, `pgai status <name>`, `pgai disconnect <name>`.
+
+With JSON output (`--json`, or stdout not a terminal) stderr is the progress stream: one JSON
+object a line, each with `event`. Besides the steps, any other text is
+`{"event":"log","level":"error"|"warn"|"info"|"debug","message":...}`: an error (also a missing
+argument or a bad option; an unknown option is named without its value), a warning (`warn`: a line
+with `Warning:`, also after a `[F001] ` prefix), the `--debug` request log (`debug`), and with
+`--self-hosted` each line of `mon local-install`
+(`"source":"mon local-install"`; `info` from its stdout, `error` from its stderr; the Grafana and
+VictoriaMetrics logins it prints at its end are masked: `pgai mon show-grafana-credentials` shows them).
+
+`pgai init` is the same for a person at a terminal: it signs in, asks for the database URL (and,
+for ClickHouse, the API key; neither is shown as typed), then runs `pgai connect`. Without a
+terminal, or with `--json`, it only points to `pgai connect`.
+
+| Option | |
+|---|---|
+| `--provider <provider>` | `clickhouse`, `rds`, `supabase` or `self-managed`; default: detected from the host |
+| `--clickhouse-key <key-id>:<key-secret>` | ClickHouse Cloud API key, for CPU, memory and disk |
+| `--self-hosted` | run the stack on this machine (`mon local-install`) instead of PostgresAI Cloud |
+| `--reset-password` | `postgres_ai_mon` exists and its password is lost: set a new one (see below) |
+| `--wait <minutes>` | how long to wait for the monitoring box; `0` does not wait (default 20) |
+| `-y, --yes` | never prompt; accept a billed box's price (`connect` does not start the browser sign-in; `disconnect` does not ask) |
+| `--coupon <code>` | promotion code for the organization's monitoring subscription |
+| `--json` | JSON output, also on a terminal |
+
+Without `--yes`, a non-interactive run for a billed box returns `action_required` with the price
+and asks you to re-run with `--yes` to accept it.
+
+| Environment | |
+|---|---|
+| `PGAI_API_KEY` | the API key, instead of signing in (agents, CI) |
+| `PGAI_MON_PASSWORD` | the password of `postgres_ai_mon`. For a new role it is set; for an existing role it is checked by logging in, and never changed. Without it a new role gets a generated password. Not needed for another database on a server PostgresAI already monitors for the organization, with `sslmode=require` or `verify-*` in the URL (see below) |
+| `PGPASSWORD` | the password for a URL without one. With a `postgres_ai_mon` URL it is the password the monitoring box gets, once the server has checked it |
+| `PGSSLMODE` | the `sslmode` for a URL without one (`sslmode` in the URL wins, as in libpq) |
+| `CLICKHOUSE_KEY_ID` + `CLICKHOUSE_KEY_SECRET` | instead of `--clickhouse-key`; read for ClickHouse hosts only |
+
+`postgres_ai_mon` is one role for the whole server, so `connect` never changes the password of an
+existing one. If the role exists and you do not have its password (a reconnect after
+`pgai disconnect`, say), `pgai connect <admin-url> --reset-password` sets a new one
+(`PGAI_MON_PASSWORD`, else generated). It is refused while another database on the same server (the same host name, in this
+organization) is monitored with the role, while a box is named `Monitoring <hash>` (the platform
+could not read its URL, so its server is not known), with `--self-hosted`, and for a database
+already connected. After the price is accepted, the run takes the platform's lock on the server (its host
+name and port, in this organization) until the box is requested. A second `--reset-password` for
+the same server exits 3 meanwhile. A run that stopped, or whose box request got no answer, frees the
+server 15 minutes after it took the lock. A platform without the lock answers "set
+`PGAI_MON_PASSWORD`" instead. Anything else that logs in as `postgres_ai_mon` (another organization,
+another host name for the same server, a connect without `--reset-password` running at the same
+time) needs the new password.
+
+Another database on a server PostgresAI already monitors for the organization needs neither: with
+`sslmode=require` or `verify-*` in the URL, the role keeps its password, the box's URL carries
+none, and PostgresAI fills in the one it kept from the first `connect` (only over TLS, each query
+parameter once, and only while a box on that server is not deleted, being deleted, or failed to
+delete). The express checkup is skipped then: it runs only as `postgres_ai_mon`, never as the
+admin. The full checkup follows on the box. On a server without TLS the kept password cannot be
+used: set `PGAI_MON_PASSWORD`, or turn TLS on; if nobody has the password, disconnect the server's
+other databases, then `--reset-password` with `PGAI_MON_PASSWORD` set to a new one, and connect
+them again with it (`connect` names them).
+
+When preparing an existing role with a supplied password (an admin URL with `PGAI_MON_PASSWORD`,
+or the role's own URL), `connect` also tries a random password as `postgres_ai_mon` to learn
+whether the server checks passwords for this host. Successful PostgresAI Cloud preparation makes
+two attempts: one in the check before the price, and one in preparation. Stopping after the check
+(for example, without accepting the price) makes one. Successful `--self-hosted` preparation
+makes one. Creating or resetting the role with an admin URL, using the platform's stored password,
+or returning an existing box's status makes no random-password attempts. A rejected supplied
+password stops before the random-password probe; that rejection is itself a failed login.
+On a server that checks passwords, each random-password attempt adds one
+`password authentication failed for user "postgres_ai_mon"` line to the server log and counts
+toward failed-login policies (credcheck, fail2ban). On a server that does not (`trust`), `next`
+says that the password was not checked; a password from `PGPASSWORD` is then not used: put it
+in the URL.
+
+A role that is not a superuser creates `postgres_ai_mon` only if it can run the whole
+preparation: `CREATEROLE`, `CREATE` on the database, `pg_stat_statements` already installed, and
+on PostgreSQL 16+ `ADMIN OPTION` on `pg_monitor` and `pg_read_all_stats`. Otherwise the SQL is
+printed and nothing is created.
+
+The host and the port are the ones in the URL: `host` or `port` in the query string is refused.
+Of the query string, the monitoring box gets `sslmode` and `application_name`; `channel_binding`
+is removed using the collector rule above, before a price is quoted or anything is changed.
+Certificate files (`sslrootcert`, `sslcert`, `sslkey`) are used for the connections from this
+machine only; with `sslmode=verify-ca` or `verify-full` and a private CA in `sslrootcert`, `next`
+says that the box has no copy of that CA.
+
+A run that fails does not leave such a role behind. The ClickHouse key and the service state are
+checked before the database is touched. If the platform refuses the launch, or a later step of the
+preparation fails, a role that this run created with a generated password is dropped again, so the
+same command can be run again. (After a platform error that is not a refusal, such as a 5xx or a
+timeout, the role stays: a monitoring box may be starting with it.)
+
+An admin URL without a database connects to `PGDATABASE`, or else to the database named like the
+user; the name of the connected database (`<host>[:<port>]/<database>`) uses that database.
+
+`pgai connect`, `pgai status` and `pgai databases` use the same words:
+
+| `status` | Meaning | Exit code |
+|---|---|---|
+| `connected` | monitoring works; `dashboard_url` is set | 0 |
+| `provisioning` | the monitoring box is being set up; check with `pgai status <name>` | 0 |
+| `disconnecting` | a disconnect is in progress (`pgai status`) | 0 |
+| `disconnected` | the result of `pgai disconnect` | 0 |
+| `action_required` | do what `next` says, then re-run | 3 |
+| `failed` | `next` has the reason | 1 |
+
+`pgai init` exits with 130 when cancelled at a prompt (Ctrl-C, Ctrl-D).
+
+`--self-hosted` starts `mon local-install` with the monitoring URL, the API key and the ClickHouse
+key in its environment (`PGAI_DB_URL`, `PGAI_API_KEY`, `CLICKHOUSE_*`), not in its arguments.
+`mon local-install` reads `PGAI_DB_URL` like `--db-url`, and `PGAI_API_KEY` only together with
+`PGAI_DB_URL`: an exported `PGAI_API_KEY` alone does not change a plain or `--demo` install.
+`mon targets add [name]` reads `PGAI_DB_URL` when argv has no `postgres://` / `postgresql://` URL
+(a URL in argv wins); with it set, a lone argument other than a plain name (ASCII letters,
+digits, `.`, `_`, `=`, `-`, with no `password=` / `pwd=`) is refused. Its default name is
+`<host>-<database>`. Percent-encode the user name and the password one at a time (all but ASCII
+letters, digits, `-`, `.`, `_` and `~`), and an `@` in the database name or the query. A user name
+or password that pgx would misread or refuse is refused; an `@` after the host is refused, since it
+cannot be told apart from one in a password; so is a control character anywhere in the URL.
+Under sudo, pass `PGAI_DB_URL` on stdin, not with `--preserve-env`: sudo logs the variables it keeps.
+Where sudoers enables I/O logging (`log_input`), sudo records stdin too: read the URL from a file
+of mode 0600 inside the root shell instead.
+
 ### Authentication
 
 Authenticate via browser to obtain API key:
@@ -250,12 +436,17 @@ postgresai mon health [--wait <sec>]  # Check monitoring services health
 
 When `--instance-id <uuid>` (or `PGAI_INSTANCE_ID`) is set, `local-install` forwards the id to the platform, which **adopts** the already-provisioned monitoring instance instead of self-registering a duplicate under an auto-created `postgres-ai-monitoring` project. The CLI then persists the adopted instance's real project to `.pgwatch-config`, so checkup reports upload alongside the rest of that instance's health data. Adoption is awaited (with one automatic retry); if it fails, the CLI warns and reports fall back to the default project until you re-run `local-install`. Without the flag, the legacy self-registration path is byte-for-byte unchanged.
 
-`local-install` writes `.env` in the monitoring directory. It preserves existing `REPLICATOR_PASSWORD` and `VM_AUTH_*` values or generates new random ones when missing; `VM_AUTH_USERNAME` defaults to `vmauth` when absent. The replication password is used by the demo PostgreSQL standby replication user, and the VM auth credentials are required before Docker Compose can provision Grafana datasources. If you run `docker compose` directly or maintain `.env` yourself, set both VM auth values before upgrading. For rotation, run `VM_AUTH_PASSWORD="$(openssl rand -base64 18)" ./scripts/rotate-vm-auth.sh` from the monitoring directory so `.env`, `sink-prometheus`, and `grafana` update together.
+`local-install` writes `.env` in the monitoring directory. It preserves existing `REPLICATOR_PASSWORD`, `VM_AUTH_*` and the VictoriaMetrics admin-endpoint keys (`VM_DELETE_AUTH_KEY`, `VM_SNAPSHOT_AUTH_KEY`, `VM_FORCE_MERGE_AUTH_KEY`, `VM_PPROF_AUTH_KEY`, added in 0.17) or generates new random ones when missing. The admin keys live on the `sink-prometheus` command line, so `mon update` and `mon update-config` also recreate that container to apply them; `mon restart` (`docker compose restart`) does not; `VM_AUTH_USERNAME` defaults to `vmauth` when absent. The replication password is used by the demo PostgreSQL standby replication user, and the VM auth credentials are required before Docker Compose can provision Grafana datasources. If you run `docker compose` directly or maintain `.env` yourself, set both VM auth values before upgrading. For rotation, run `VM_AUTH_PASSWORD="$(openssl rand -base64 18)" ./scripts/rotate-vm-auth.sh` from the monitoring directory so `.env`, `sink-prometheus`, and `grafana` update together.
 
 #### Monitoring target databases (`mon targets` subgroup)
 ```bash
 postgresai mon targets list                       # List databases to monitor
 postgresai mon targets add <conn-string> <name>   # Add database to monitor
+# Same, URL kept out of argv and out of the sudo log (read from stdin, not exported),
+# unless sudoers enables I/O logging (log_input), which records stdin:
+printf '%s\n' "$URL" | sudo sh -c 'IFS= read -r PGAI_DB_URL; export PGAI_DB_URL; exec postgresai mon targets add <name>'
+# With log_input, read it from a file of mode 0600 inside the root shell:
+sudo sh -c 'IFS= read -r PGAI_DB_URL < /path/to/db-url; export PGAI_DB_URL; exec postgresai mon targets add <name>'
 postgresai mon targets remove <name>              # Remove monitoring target
 postgresai mon targets test <name>                # Test target connectivity
 ```
@@ -271,6 +462,35 @@ postgresai mon check                          # System readiness check
 postgresai mon shell <service>                # Open shell to monitoring service
 ```
 
+### PromQL queries (`promql`)
+
+Ask a monitoring instance a PromQL question through the platform. The platform
+never connects to the instance: it queues the query as a job, the instance picks
+it up on its next poll, runs it against its own metric store, and posts the
+answer back.
+
+```bash
+# instant query
+pgai promql 'up' --instance <instance-uuid>
+
+# range query
+pgai promql 'sum(rate(pgwatch_db_stats_xact_commit[5m]))' \
+  --instance <instance-uuid> \
+  --range --start 2026-09-21T00:00:00Z --end 2026-09-21T01:00:00Z --step 60
+
+# on the box itself, --instance is read from .pgwatch-config
+pgai promql 'up'
+```
+
+`--at <time>` evaluates an instant query at a given moment (ignored with
+`--range`). `--json` prints every point instead of the first and last per series.
+The wait is sized from the instance's poll pacing; `--timeout` overrides it. A
+result too large for the byte budget is trimmed and flagged `truncated`.
+
+Requires platform-all !809
+(https://gitlab.com/postgres-ai/platform-all/-/merge_requests/809); until it is
+deployed the command returns a PGRST202 404.
+
 ### MCP server (`mcp` group)
 
 ```bash
@@ -299,14 +519,15 @@ required** — the server will not assume an organization. Call `orgs_list` (or
 run `pgai orgs`) to discover the available ids.
 
 Tools exposed:
-- `list_issues`: returns the same JSON as `postgresai issues list` (args: `{ org_id, status?, hidden_only?, limit?, offset?, debug? }`).
+- `list_issues`: returns the same JSON as `postgresai issues list` (args: `{ org_id, status?, hidden_only?, limit?, offset?, debug? }`). Unlike the CLI, omitting `status` returns open and closed issues; pass `status: "open"` to match the CLI default.
 - `view_issue`: view a single issue with its comments (args: `{ issue_id, org_id, debug? }`).
-- `create_issue`: create a new issue (args: `{ title, description?, org_id, attachments?, debug? }`).
-- `update_issue`: update title/description/status/labels (args: `{ issue_id, org_id, title?, description?, status?, labels?, attachments?, debug? }`).
+- `create_issue`: create a new issue (args: `{ title, description?, org_id, project_id?, labels?, attachments?, is_hidden?, debug? }`).
+- `update_issue`: update title/description/status/labels/is_hidden (args: `{ issue_id, org_id, title?, description?, status?, labels?, attachments?, is_hidden?, debug? }`).
 - `post_issue_comment`: post a comment (args: `{ issue_id, org_id, content?, parent_comment_id?, attachments?, debug? }`).
 - `update_issue_comment`: update an existing comment (args: `{ comment_id, org_id, content?, attachments?, debug? }`).
 - `upload_file`: upload a local file and return the storage URL plus a ready-to-paste markdown link (args: `{ path, org_id, debug? }`).
 - `download_file`: download a file from storage (args: `{ url, org_id, output_path?, debug? }`).
+- `connect_database`: `pgai connect` as a tool (args: `{ database_url, org_id, provider?, clickhouse_key?, yes?, coupon?, debug? }`). Returns the same JSON (`status`: `connected`, `provisioning`, `disconnecting`, `action_required` or `failed`; `dashboard_url`; `next`). For a billed box, the tool first returns the price with `action_required`; an explicit call with `yes: true` accepts it. `coupon` supplies a promotion code. It does not wait for the monitoring box: call it again to see the status. `database_url` must carry its password, and only the query parameters `sslmode`, `channel_binding`, `application_name` (and `password`); `PGAI_MON_PASSWORD`, `PGPASSWORD` and `CLICKHOUSE_KEY_ID` + `CLICKHOUSE_KEY_SECRET` of the server process are not used, a TLS failure is not retried in plaintext, and `--self-hosted` is CLI-only. For another database on a server PostgresAI already monitors for the organization, an admin `database_url` with `sslmode=require` (or `verify-*`) is enough: PostgresAI fills in the password of `postgres_ai_mon` it keeps.
 
 #### `attachments` parameter (issue/comment tools)
 
@@ -350,11 +571,14 @@ sensitive.
 ### Issues management (`issues` group)
 
 ```bash
-postgresai issues list                                       # List issues (shows: id, title, status, created_at; is_hidden only when set)
+postgresai issues list                                       # List OPEN issues (shows: id, title, status, created_at; is_hidden only when set)
+postgresai issues list --status closed                       # Only closed issues (--status all for both)
 postgresai issues list --hidden-only                         # Only hidden issues (PostgresAI staff)
 postgresai issues view <issueId>                             # View issue details and comments
-postgresai issues create --org-id <id> --title <t>           # Create a new issue
+postgresai issues create --org-id <id> <title>               # Create a new issue
+postgresai issues create --org-id <id> <title> --hidden      # Create a hidden issue (PostgresAI staff)
 postgresai issues update <issueId> [--title ... --status ...]# Update an existing issue
+postgresai issues update <issueId> --hidden|--no-hidden      # Hide / unhide an issue (PostgresAI staff)
 postgresai issues post-comment <issueId> <content>           # Post a comment to an issue
 postgresai issues update-comment <commentId> <content>       # Update an existing comment
 postgresai issues files upload <path>                        # Upload a file, print URL + markdown
@@ -370,7 +594,11 @@ postgresai issues files download <url> [-o <path>]           # Download a file
 Hidden issues are staff-internal. `issues list` and `issues view` mark them
 with `is_hidden: true`; the key is omitted entirely otherwise, so ordinary
 issues look exactly as they always have. `--hidden-only` lists just the hidden
-ones, filtered server-side.
+ones, filtered server-side. `issues create --hidden` creates one, and
+`issues update --hidden` / `--no-hidden` hides or unhides an existing issue
+(MCP: `is_hidden` on `create_issue` / `update_issue`). The CLI does no staff
+check of its own: the platform refuses a visibility change for a non-staff
+credential with a plain error, and the CLI prints it and exits non-zero.
 
 Staff access is granted per credential, not per person, and a credential that
 does not qualify simply sees nothing — `--hidden-only` returns an empty list
@@ -556,7 +784,7 @@ PGPASSWORD=... postgresai checkup \
   `postgresai checkup <ID> <conn>`); stdout is then a one-key object.
 - **stderr** carries only human-readable diagnostics (progress, warnings,
   errors). It never contains report JSON — machine consumers should read stdout
-  only. Do not parse stderr as JSON.
+  only. Do not parse stderr of `checkup` as JSON (that of `pgai connect` is JSON lines, see above).
 - **Exit codes**: `0` on success; non-zero when the run fails (connection
   failure, insufficient permissions, an unknown/unavailable check ID, or a
   failing check). On a non-zero exit, no JSON report object is written to