@302ai/media-studio-cli 0.1.0-beta.1 → 0.1.0-beta.3

package/README.md

@@ -10,6 +10,19 @@ npm install -g @302ai/media-studio-cli
 # requires Node.js >= 22
 ```
 
+Newer, less tested prerelease builds:
+
+```bash
+npm install -g @302ai/media-studio-cli@beta
+```
+
+> **No stable release exists yet.** `latest` points at a prerelease, so both
+> commands above currently install the same build. Staging-server visibility is
+> gated on the package *version* carrying a prerelease tag — not on the
+> dist-tag — so it is on for both: **Staging** appears in `msc login` and in
+> `--region` whichever way you install. A future stable release will hide it
+> from both channels.
+
 > If you installed via **bun** and get `command not found`: bun's global bin
 > dir is not on PATH by default. Run once:
 >
@@ -68,6 +81,56 @@ Point at a different server via `MEDIA_STUDIO_API_URL` env var, or
 `msc login --region local|cn|default` (the server you log into is saved and
 reused).
 
+### Staging server (expired TLS certificate)
+
+The staging server's certificate is expired (ops declines renewal), so the
+CLI skips TLS certificate verification **only while pointed at the staging
+host**; the server choice itself is the opt-in, and the default / CN hosts
+always verify. The interactive `msc login` region list shows each server's
+URL and marks Staging with the auto-off behavior; `msc login --region
+staging` and `MEDIA_STUDIO_API_URL=https://media.tool302.com` behave the
+same.
+
+Stable (production) builds hide Staging from the `msc login` region menu, but
+a persisted staging `auth.json` still auto-bypasses TLS verification — this is
+intentional (the login persists across upgrades), not an oversight.
+
+The whitelist is the only way the bypass turns on — no environment variable can
+extend it to another server, so production can never skip verification. To
+force verification back **on** while pointed at staging (once ops renews the
+certificate, or to debug its chain):
+
+```bash
+MEDIA_STUDIO_INSECURE_TLS=0 msc chat "hi"   # also accepts "false"
+```
+
+Plain-`http://` servers skip the bypass entirely (nothing to verify). The
+bypass prints nothing: the staging choice is already stated in the `msc login`
+menu and here, so no warning repeats on every command (`--help` and `--version`
+included, whose output scripts and agents parse).
+
+### TLS-intercepting proxies
+
+If browser SSO login works but every API call fails with `fetch failed`, a
+TLS-intercepting proxy (Clash/FlClash TUN mode, corporate MITM) is breaking
+certificate verification (`unable to verify the first certificate`).
+Node/Bun do not use the OS keychain, so a proxy CA trusted by your browser
+is not trusted by the CLI. Either trust the proxy CA explicitly:
+
+```bash
+export NODE_EXTRA_CA_CERTS=/path/to/proxy-ca.crt
+```
+
+or skip verification for the CLI only (no certificate checks). The staging host
+already does this automatically, so this is only needed for other servers — and
+it is now the only way to bypass a non-staging host, since no `msc` flag or env
+var does so. Note it is process-global: every host the CLI talks to stops being
+verified.
+
+```bash
+NODE_TLS_REJECT_UNAUTHORIZED=0 msc sessions
+```
+
 ## Development
 
 ```bash