feat(cli): Warn before commands that desync a Frappe Cloud bench - #1728

Problem

On Frappe Cloud, the bench inside the container is a replica, not the source of truth. Press owns the Bench and Site records and rebuilds the container from an image on every deploy. Commands run by hand over SSH drift the two apart, and the drift is silent:

• bench --site x install-app erpnext — the dashboard still shows the old app list, and the app is gone after the next deploy
• bench --site x drop-site — Press keeps showing the site as active, and keeps billing it
• bench get-app / bench update — discarded on the next deploy, and the recorded app hashes no longer match
• bench set-config / bench config — overwritten on the next config push

Each of these turns into a support ticket that starts with "the dashboard is wrong".

What this does

Prompts before those commands and explains which record goes out of sync:

This bench is managed by Frappe Cloud.

  $ bench --site foo.frappe.cloud install-app erpnext

Frappe Cloud tracks installed apps on the Site record. The app will be
missing from the dashboard and will not survive the next deploy.

Use the Frappe Cloud dashboard instead.

Run it anyway? [y/N]:

Declining exits non-zero. Accepting runs the command — the guard is advisory, not a lock.

When it fires

All of these must hold, so it's inert everywhere except an interactive shell on a managed bench:

Where the hook lives

In cli(), after the --help/no-args early return and before both dispatch paths. This placement is load-bearing: commands not registered with bench (everything --site-scoped) are handed to frappe via os.execv, which replaces the process. Anything downstream of that can't prompt.

Guarded commands

Site state (tracked on the Site record): new-site, drop-site, install-app, uninstall-app, set-config, remove-config, restore, reinstall, migrate, rename, set-admin-password

Bench state (tracked on the Bench record / Release Group): get-app, new-app, remove-app, update, switch-to-branch, switch-to-develop, retry-upgrade, pip, setup, config, start, restart, drop

Aliases are resolved from the command registry, not listed in the table: MultiCommandGroup files one command object under several names, so bench get (= get-app) and bench remove / bench rm (= remove-app) are covered, and an alias added to a guarded command later needs no table edit. A test walks the registry and fails if any alias of a guarded command is unguarded.

Notes

No --yes flag. frappe's reinstall already defines its own --yes, and unregistered commands are execv'd to frappe verbatim — a bench-level flag would either collide or have to be stripped from argv, changing what bench --site x reinstall --yes means. BENCH_SKIP_PROD_GUARD=1 is the bypass instead, and the abort message names it.

No agent changes needed. Verified that agent/bench.py builds docker exec without -t, so agent-issued commands are non-interactive and skip the prompt.

Testing

15 unit tests in bench/tests/test_prod_guard.py cover detection, the command table, and every skip path.

Manually against a real bench:

• TTY + FRAPPE_CLOUD=1 + install-app, declined → exit 1, never reached frappe
• Same command non-interactively → no prompt, passed straight through to frappe
• TTY + install-app --help → help printed, no prompt

Companion PR

Requires frappe/press#7130 to write the marker. This PR is a no-op without it.

🤖 Generated with Claude Code