Document the CLI refusing a project .env target or credential

fabric/cluster-creation-management.md

@@ -81,7 +81,7 @@ Clusters are provisioned in real time, as soon as selections are complete
 
 ## Connecting the Harper CLI to a Cluster
 
-The cluster's **Config → Overview** page exposes its **Application URL** — the hostname the Harper CLI and SDKs target. Pass it to `harper login` to authenticate; the CLI stores the token so subsequent commands don't need credentials repeated. If the current directory already has a `.env` file that sets no target, it also appends `HARPER_CLI_TARGET` to it.
+The cluster's **Config → Overview** page exposes its **Application URL** — the hostname the Harper CLI and SDKs target. Pass it to `harper login` to authenticate; the CLI stores the token so subsequent commands don't need credentials repeated. It also saves the URL as the CLI's default target. From v5.4.0, the CLI stops with an error if a `.env` file in the current directory sets a name it refuses, such as `HARPER_CLI_TARGET`, and your environment does not. Remove that line. See [Project `.env` files](/reference/v5/cli/authentication#project-env-files).
 
 ```bash
 harper login <Application URL>

learn/administration/safe-deployments-and-rollback.mdx

@@ -28,26 +28,20 @@ This guide deploys a Harper application to a cluster, waits until every node run
 
 ### Log in
 
-Set the cluster's Operations API URL in your project's `.env`:
+Set the cluster's Operations API URL in your shell, then log in:
 
 ```bash
-# .env
-HARPER_CLI_TARGET='https://my-cluster.example.com:9925'
+export HARPER_CLI_TARGET='https://my-cluster.example.com:9925'
+harper login "$HARPER_CLI_TARGET"
 ```
 
-`npm create harper@latest` asks for your cluster URL and writes it here, adding `https://` if you omit the scheme and port `9925` if you omit the port. If you skipped the prompt, replace the placeholder. From the project directory, log in:
+Enter the cluster's admin username and password. The CLI saves a token in `~/.harperdb/credentials.json`.
 
-```bash
-harper login
-```
-
-Press Enter to accept the `.env` value at the **Cluster Target URL** prompt, then enter the cluster's admin username and password. The CLI saves a token in `~/.harperdb/credentials.json`, not in `.env`.
+Commands such as `harper deploy`, `harper list_deployments`, and `harper get_job` then need no `target=`. The export keeps this shell's commands from falling back to the last cluster you logged in to from any project, so set it again in each new shell. CI sets the same variable from a repository variable. See [how the CLI picks a target](/reference/v5/cli/authentication#how-the-cli-picks-a-target).
 
-<VersionBadge version="v5.1.0" />
-
-The CLI loads `.env` from the directory you run it in. Commands such as `harper deploy`, `harper list_deployments`, and `harper get_job` then need no `target=`. Pinning the target here keeps this project's commands from falling back to the last cluster you logged in to. An existing environment variable wins over `.env`, so CI can still set `HARPER_CLI_TARGET` from a repository variable. See [authentication](/reference/v5/cli/authentication) for the full precedence rules.
+<VersionBadge type="changed" version="v5.4.0" />
 
-The target URL is not a secret. To share it with your team, remove `.env` from the template's `.gitignore` and commit the file, or force-add it. Templates ignore `.env` and `.env.*`, except `.env.example`. Keep credentials such as `CLI_TARGET_USERNAME` and `CLI_TARGET_PASSWORD` out of it: the deploy upload includes `.env`, so its contents reach every node.
+Remove any `HARPER_CLI_TARGET` line from your project's `.env`. `npm create harper@latest` writes one there. From v5.4.0, the CLI stops with an error while the file sets it and your environment does not. To share the target with your team, pass `target=` in a `package.json` script. See [Project `.env` files](/reference/v5/cli/authentication#project-env-files).
 
 ### A Harper backend
 
@@ -84,11 +78,10 @@ npm run build
 rm -rf deploy && mkdir deploy
 cp -R dist schemas resources deploy/
 cp deploy.config.yaml deploy/config.yaml
-cp .env deploy/.env
 (cd deploy && harper deploy project=my-app restart=true)
 ```
 
-The CLI reads `.env` from the directory it runs in, so the staged directory needs this copy to find the target. It holds only the target URL, so shipping it is harmless. The staged directory has no `package.json`, so the nodes skip the install step. If your resources import npm packages, add a `package.json` to `deploy/` that lists only those runtime dependencies. Harper Studio [deploys itself this way](https://github.com/HarperFast/studio/blob/stage/.github/actions/studio-deploy/action.yaml).
+The subshell inherits `HARPER_CLI_TARGET`, so the CLI needs no `.env` in the staged directory. If your release configuration keeps `loadEnv`, copy only the application's keys to `deploy/`, under a file name its `files` lists. The staged directory has no `package.json`, so the nodes skip the install step. If your resources import npm packages, add a `package.json` to `deploy/` that lists only those runtime dependencies. Harper Studio [deploys itself this way](https://github.com/HarperFast/studio/blob/stage/.github/actions/studio-deploy/action.yaml).
 
 ### Deploy from GitHub Actions
 
@@ -208,7 +201,7 @@ harper deploy project=my-app restart=rolling target=https://node-1.example.com:9
 )
 ```
 
-Jobs are not replicated, so the script deploys to and polls one node rather than the load-balanced cluster URL in `.env`, where a poll can reach a node that never saw the job. See [the job lives on one node](../developers/deploying-from-ci.mdx#path-a-deploy-a-tagged-release-from-your-repository). Without certification, including before v5.4.0, a `COMPLETE` job can still leave a node it could not reach on the old release. Check the serving version on every node afterwards.
+Jobs are not replicated, so the script deploys to and polls one node rather than the load-balanced cluster URL in `HARPER_CLI_TARGET`, where a poll can reach a node that never saw the job. See [the job lives on one node](../developers/deploying-from-ci.mdx#path-a-deploy-a-tagged-release-from-your-repository). Without certification, including before v5.4.0, a `COMPLETE` job can still leave a node it could not reach on the old release. Check the serving version on every node afterwards.
 
 Two deploy parameters control replication failures:
 

reference/backups/operations.md

@@ -25,7 +25,11 @@ Every operation on this page can be run from the CLI under its operation name, f
 
 Like any [CLI operation](../cli/operations-api-commands.md), backup commands also accept a remote `target=<url>` to run against another instance instead of the local one (see [Remote Operations](../cli/overview.md#remote-operations)). With a remote target the operation is always forwarded — there is no offline path.
 
-A target set with `HARPER_CLI_TARGET` or `CLI_TARGET` is always forwarded too, including one that `harper login` added to a `.env` file. `harper logout` does not remove a `.env` entry, so delete that line to run commands offline.
+A target set with `HARPER_CLI_TARGET` or `CLI_TARGET` in the environment is always forwarded too. Unset it to run commands offline.
+
+<VersionBadge type="changed" version="v5.4.0" />
+
+A `.env` file in the current directory cannot set the target. If it sets either variable, or another [name the CLI refuses](../cli/authentication.md#project-env-files), and the environment does not, a backup command stops with an error naming the keys. It stops before forwarding the operation or touching a file, whether or not Harper is running. Before v5.4.0 the file's target was forwarded, including one that `harper login` added. `harper logout` does not edit the file, so delete that line.
 
 A target saved by `harper login` is also forwarded, with one exception. If the saved target is a loopback address (`localhost`, `127.x` or `::1`) and the local server is stopped: