insta upgrade silently switches the environment back to prod

[tonychang04]

What happened

With the CLI on staging (insta env → staging, ~/.insta/config.json apiUrl https://api.staging.instacloud.com), I ran:

insta upgrade          # 0.0.45 -> 0.0.47, via install.sh

Afterwards, with no other env command:

insta env
  env:  prod
  api:  https://api.instacloud.com

The upgrade reset the environment to prod. Nothing announced it — insta upgrade prints the installer's onboarding banner, not an upgrade report, so there was no signal the environment had changed.

Why this is dangerous

I then ran insta project create, services add compute, compute volume --size 1 and insta deploy believing I was on staging. All of it landed on production under a real account. The only tell was a .compute.instacloud.com hostname where I expected .staging.instacloud.tech, and a Fly-shaped error message where I expected a microvm one. A user who does not know the two domains apart would never notice.

An upgrade must never change which cloud the user is talking to. The environment is user state, like login; the binary is not.

Likely cause

insta upgrade on the binary channel runs curl install.sh | sh with inherited stdio. install.sh is an installer and (presumably) writes a default config / default env for a fresh machine, clobbering the existing selection. upgrade should either not re-run first-install config steps, or install.sh must preserve an existing ~/.insta/config.json env/apiUrl when present.

Fix expectations

• insta upgrade preserves env, apiUrl, and login exactly.
• Regression test: config on staging → upgrade → config still staging (negative-controlled: fails on current install.sh).
• Related: fix(upgrade): one live source of truth for "latest", and a cache that cannot pin an install #141 (upgrade reports the version transition) — that report should also state the env it left the user on.

Observed 2026-08-26 on macOS, binary channel.

🤖 Generated with Claude Code