Blog
When the CLI Points at the Wrong Host
Staging flags, leftover localhost URLs, and a production token aimed at a sandbox all look like auth bugs. Print the host you called. Developers cannot see the default you compiled in.
2026-09-26 · 6 min read · AethelLayer
Print the host on every failure
The error should include the scheme and host, not the path if the path has an id, and never the query string. 'Auth failed' against an unspoken localhost is an hour of guessing.
If a flag selects the environment, echo the flag and the host it resolved to. Defaults that differ from the README are a bug.
Tokens are scoped to a host
A production key against a staging host should be its own code, not a generic 401. Say the two hosts. Do not print the key.
Device-code login must open the verification URL for the same host the token request uses. Mixing them is a client bug that looks like an IdP outage.
Samples should refuse the dangerous default
If the example still contains http://localhost and they pointed the CLI at production by accident, fail with a named code before you send traffic. Surprises in production are how trust dies.
Capture the host and the flag. The cluster tells you the README and the default disagree.
One draft for the wrong default
Twenty people hitting production while they think they are on staging is one default to change. Quote a single sentence from the probes and fix the flag's default.
A person reviews the draft before it becomes an issue. Hostnames are not secrets, but the rest of the argv might be.
Keep reading
Capture the failure before they leave
Capture the failure before they leave. Book early access or talk to sales, then install @aethellayer/sdk when you are onboarded.