openpouch

List the files in a named app's persistent /data volume — names, sizes and timestamps only, never contents. Owner-only (account key). Use it to verify a data push/migration landed.

Download a named app's persistent /data volume as a gzipped tar file (L13 — the BACKUP primitive: your human's data is never locked in). Owner-only (account key). Writes the archive to a local path and returns its location + size.

Replace a named app's persistent /data volume with a local directory's contents (L13 — the migration/restore primitive). The server stops the app for the write and restarts it health-gated, so files like a SQLite DB are never swapped under a running process. Owner-only (account key); file CONTENTS never appear in logs or results (counts/sizes only). Typical migration: export data from the old host (your own means — you own the code), then push it here.

Delete one of YOUR OWN instant-lane apps by name (slug) → frees a quota slot. This is the self-service fix for a 'limit reached' deploy error: list your apps, delete an unused one, redeploy. Owner-only — it uses your account key and the server verifies ownership, so you can never delete another account's app. Deleting an ephemeral preview is NOT a governed-production action, so it needs no approval (there is still no approve tool, D13). Returns the removed name + a plain-language `summary`.

Zero-config INSTANT preview on openpouch's own infra — the `openpouch deploy` command (was CLI-only; Codex 2026-07-04). No account, no provider key, no manifest needed (a saved openpouch API key lifts the deploy into your tier; otherwise anonymous). Uploads the folder, builds on deploy (dynamic Node apps run in a container), probes health, and returns top-level `url`, `healthStatus` (+ `pending`), and a plain-language `summary` to relay to your human. The private claim link (a save token — like a password) is REDACTED from the result BY DEFAULT here, because tool results flow through chat context; it is saved locally to .openpouch/claim.json (0600, gitignored), so nothing is lost. Env var VALUES are secrets: injected into the container only, never in output or evidence (names only). For a full-stack app set healthPath (e.g. /api/health) so the deploy is held to its API too, not just `/`.

Deploy the preview environment through the governed pipeline (policy check → deploy → poll → smoke → evidence). Default policy allows previews autonomously. For the zero-config instant preview (no manifest/provider key) use openpouch_deploy instead. On success the live URL is returned at top-level `url`, plus a plain-language `summary` to relay to your human.

Deploy production through the governed pipeline. If policy requires approval, this returns approvalRequest{id} with isError — ask your HUMAN to run `openpouch approve <id>` in their own terminal, then call this tool again. Agents cannot approve; there is intentionally no approve tool. Every result carries a plain-language `summary` to relay to your human; on a live deploy the URL is at top-level `url`.

Initialize a project for openpouch: detects framework/build/env vars, writes deploy.manifest.json + deploy.policy.json (default policy: previews autonomous, production requires human approval), auto-matches an existing provider service by name. Idempotent.

Answer: what is deployed, where, on which commit, which required env vars are missing (names only — never values), and what drift exists between manifest and provider. Env vars passed at deploy time (--var/--env-file) appear as `deployProvided` (names from local evidence — the instant lane never exposes them via the API). Read-only. The result carries a plain-language `summary` you can relay directly to a non-technical human.

List the instant-lane apps owned by the current openpouch account key: name (slug), kind (static/dynamic), status, live URL, and expiry. Read-only; needs an account key (anonymous previews aren't grouped under an account → an empty list with a signup pointer). Carries a plain-language `summary` to relay to your human. Pair with openpouch_delete to free a quota slot when a deploy hits a 'limit reached' error.

List pending approval requests (read-only). Approving itself is human-only via `openpouch approve <id>` in an interactive terminal — by design not available to agents.

Structured runtime logs ({timestamp, message}) of the mapped service. Read-only. This is the first step of the self-repair loop: when a deploy comes back unhealthy (a failed verify, a non-200 app, or a pending/not-yet-live URL), read the logs to find the cause, fix the code or config, redeploy, then verify — repeat until it passes.

Per environment: the policy decision (allowed / requires-approval / denied), blockers, readiness, and concrete next steps including the human-approval path. Read-only — reports, never acts.

Redeploy the recorded rollback anchor commit (the deploy that was live before the latest one). Approval-gated like any write action — may return approvalRequest{id} for your human.

Get a hosted-checkout URL for a paid openpouch tier (plan). Payment is deliberately a HUMAN step: hand the returned checkoutUrl to your human — they pay in the browser at the Merchant of Record; agents never enter payment data and there is no pay tool. The account tier updates automatically after payment (verify with openpouch_whoami). Needs an API key; returns availablePlans in the error when the plan name is unknown.

Run the healthcheck/smoke against the environment's live URL and append the results to the evidence (deploy.evidence.json + DEPLOYMENT.md). For a full-stack app pass healthPath (e.g. /api/health) — it is checked IN ADDITION to `/`, because a live shell can hide a dead API. The result carries a plain-language `summary` (healthy / has a problem) you can relay to your human.

Report the openpouch account behind the current API key: tier (plan) and current usage (live apps, deploys this hour/day), or that the caller is anonymous. Read-only. The key is read from OPENPOUCH_API_KEY / ~/.openpouch/openpouch-run.key and never echoed. Carries a plain-language `summary` you can relay to your human. (Signup/activation are CLI/web only — they involve a human email or browser step.)