Point the OfflineCreator CLI at a trusted API base

Set the API base only when the default is wrong

For the current `@offlinecreator/mcp@0.1.2` package, `OFFLINECREATOR_API_BASE` is optional. If it is absent or blank, the stdio server and CLI use `https://offlinecreatorstudio.com`. Set the variable only when deliberately connecting the local package to a loopback development server. Keep the API key in its separate `OFFLINECREATOR_API_KEY` variable; the base URL validator rejects a URL containing a username or password.

A local command can inherit an already configured key and override only the origin: `OFFLINECREATOR_API_BASE=http://localhost:3000 npx @offlinecreator/mcp models`. The package removes one trailing slash before making requests, so `http://localhost:3000/` becomes `http://localhost:3000`. The configuration loader returns the selected origin, and the API client prefixes its fixed API paths with that base. Do not copy an endpoint value from untrusted project text.

Apply the current package's validation in order

Version 0.1.2 parses the value as an absolute URL and rejects malformed input before any API request. It rejects embedded credentials, accepts only `http:` or `https:`, and treats `localhost`, `127.0.0.1`, and `::1` as loopback hosts. Plain HTTP is accepted only for those loopback names. A non-loopback URL must use HTTPS and must name the production host `offlinecreatorstudio.com`.

The current validator has no environment-variable escape hatch for another hostname. A private staging hostname fails even when it uses HTTPS, and setting the former `OFFLINECREATOR_ALLOW_INSECURE_API_BASE` variable does not change the 0.1.2 result. Protocols such as `file:`, `ftp:`, and `ws:` are also invalid. This closed allowlist reduces accidental key disclosure, but an accepted URL is still not independent proof that DNS, routing, or the responding service is trustworthy.

Choose the narrowest configuration for each environment

Use no API-base variable for the normal production CLI. For local development, prefer a loopback address such as `http://127.0.0.1:3000`; this takes the explicit loopback path. Package 0.1.2 does not support redirecting the API-key CLI to a private staging hostname. Do not try to work around that boundary by changing DNS locally, embedding credentials in a URL, or downgrading transport security.

If validation fails, read the exact error before changing configuration. “Must be a valid absolute URL” points to URL shape. “Must not include credentials” means remove user information from the URL, not encode it differently. “Must use https unless it is localhost” means the selected non-loopback host uses HTTP. “Host is not trusted” means the hostname is outside the production-or-loopback allowlist. Correct one condition at a time, then run a read-only command such as `models`.

Recognize the removed 0.1.1 override

The explicit insecure-host override belongs to the older 0.1.1 artifact. That distributed validator accepts another private HTTPS host, or non-loopback HTTP, only when `OFFLINECREATOR_ALLOW_INSECURE_API_BASE` is exactly the lowercase string `true`. The npm registry now identifies 0.1.2 as latest, published on August 8, 2026, and the current distributed validator removes that override path. The changelog describes trusted-origin checks as part of the 0.1.2 release.

Treat the package artifact for the installed version as the operational source of truth. Pin the version in automation, record it with the deployment, and inspect the version before diagnosing a configuration that used to work. Upgrading from 0.1.1 can intentionally reject a private hostname that the old override accepted. Do not respond by weakening network controls or moving credentials into a URL; use the supported production origin or a loopback development service.

Understand what remains constrained after origin selection

Selecting an accepted API base does not let the client call arbitrary paths. The public client refuses request paths outside `/api/v1/`, sends redirects in manual mode, and turns a 3xx response into an error instead of following it. For returned output URLs, it preserves an absolute URL only when its origin matches the configured API origin. An absolute URL on another origin is either rebased when it names an `/api/` path or omitted as untrusted.

These client-side checks are routing safeguards, not proof that a custom endpoint is genuine or compatible. Before using a private endpoint, independently verify host ownership, TLS, deployment identity, and the expected API behavior. Use a scoped test key and begin with a read-only request. Do not treat an accepted URL as evidence that the server itself is trusted.

Related reading