fix(config): default cloud API to api.instacloud.com (not legacy beta host)

[tonychang04]

Onboarding is agents.instacloud.com, but the CLI's hardcoded DEFAULT_API still pointed at the legacy beta-api.insta.insforge.dev — so a fresh install talked to an insforge.dev domain instead of the instacloud.com brand.

Same backend, confirmed: identical 401 {"error":"unauthorized"} on /orgs and 400 on /auth/cli/authorize on both hosts; api.instacloud.com resolves + serves the insta cloud API.

Blast radius: only fresh installs (no persisted config). A persisted apiUrl from a prior login, or INSTA_API_URL, still wins — existing logins are undisturbed. Single-line change; 77/77 tests green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GMbAe5K1RfwaAcge5inX7P

---

Summary by cubic

Switched the CLI’s default cloud API to https://api.instacloud.com (replacing https://beta-api.insta.insforge.dev) so fresh installs use the branded domain that matches agents.instacloud.com onboarding. Persisted apiUrl or INSTA_API_URL still override, so existing logins are unaffected.

^{Written for commit 0ffa238. Summary will update on new commits.}

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[jwfing]

Review: fix(config): default cloud API to api.instacloud.com

Summary: Clean, self-contained one-line change to DEFAULT_API that repoints the fresh-install default from the legacy beta-api.insta.insforge.dev host to the branded api.instacloud.com, with override precedence and existing logins correctly preserved.

Requirements context: No matching spec/plan found — this repo has no docs/superpowers/ or docs/specs/ directory, so I assessed against the PR description alone plus the repo-local .claude/skills/developing-insta-cli conventions.

---

Findings

Critical

(none)

Suggestion

• Software engineering — no test pins the default host. src/config.ts has no corresponding test file, and this PR adds none. A regression test asserting readGlobal() returns https://api.instacloud.com when there's no config file and INSTA_API_URL is unset (and that a persisted apiUrl / INSTA_API_URL still wins) would lock in both the new default and the override precedence at src/config.ts:32,34. Low value on its own since the default is a plain constant, but it would guard the precedence logic, which is the part with actual behavior. Non-blocking.

Information

• Functionality — "same backend" is an operational claim, not code-verifiable. The diff is correct regardless, but the PR's core assertion (that api.instacloud.com fronts the identical backend as the legacy host) can't be validated from the source. Worth a final DNS/TLS + auth smoke check against api.instacloud.com before/after merge, since fresh installs will send auth tokens there (src/api.ts:62).
• Functionality — legacy-host users are intentionally not migrated. Users who logged in on a prior CLI build have beta-api.insta.insforge.dev persisted in ~/.insta/config.json, so they keep hitting the old host until they re-login or set INSTA_API_URL. This matches the PR's stated blast radius ("existing logins undisturbed"); flagging only so it's on record if/when the legacy host is decommissioned.
• Software engineering — no stale references. Confirmed the old host appears nowhere else in the repo (docs, install.sh, agents.sh, tests); install.sh/agents.sh don't hardcode an API host, so DEFAULT_API remains the single source of truth for fresh installs. The comment added at src/config.ts:21-23 is clear and matches the file's existing commenting style.

Security

No security-relevant regressions. Default remains HTTPS; no new user input, no secrets logged, no auth/authorization checks changed, no new dependencies. The only security-adjacent consideration is the host-trust point noted under Information (fresh installs will send tokens to the new domain).

Performance

No performance-relevant changes — this is a static constant swap with no new I/O, loops, or allocations.

---

Verdict: approved

No Critical findings. The change is minimal, correct, and complete, with override precedence and existing logins preserved. Suggestion/Information items above are non-blocking. (This is the bot's assessment — explicit GitHub approval remains a separate human action.)

[jwfing]

Review — fix(config): default cloud API to api.instacloud.com

Summary: A minimal, correctly-scoped change that swaps the fresh-install default host from the legacy beta-api.insta.insforge.dev to the branded api.instacloud.com, plus an explanatory comment — override precedence (INSTA_API_URL > persisted apiUrl > default) is untouched, so existing logins are unaffected.

Requirements context: No matching spec/plan found — this repo has no /docs/superpowers/ (nor a docs/ directory at all). Assessed against the PR description, .claude/skills/developing-insta-cli/SKILL.md, and the surrounding code.

---

Critical

(none)

Suggestion

• Software engineering — no test locks the default value. src/config.ts:24 is the only place DEFAULT_API is defined, and no test in test/ asserts readGlobal()'s fallback host (grep for DEFAULT_API/instacloud/beta-api across test/ is empty). The PR's "77/77 green" is therefore expected-but-uninformative for this change — the suite would stay green even if the host were wrong. A one-line test (readGlobal() with no config file and no INSTA_API_URL → apiUrl === 'https://api.instacloud.com') would guard against an accidental revert and document the intended default. Low blast radius, non-blocking.

Information

• Functionality / docs — README quickstart states a different default. README.md:45 says the control plane "defaults to http://localhost:8080", which contradicts DEFAULT_API being a cloud host. This is pre-existing (it disagreed with the old beta-api… value too) and thus out of scope for this PR, but since the PR is specifically about the default host, it's a natural moment to correct the doc — either here or in a follow-up.
• Security / correctness — depends on an infra fact I can't verify from code. The change is only correct if api.instacloud.com resolves, serves the same backend, and presents a valid TLS certificate — fresh installs will send OAuth/login credentials there on first use. The PR body documents this verification (identical 401 on /orgs, 400 on /auth/cli/authorize on both hosts), and instacloud.com is already the org-owned onboarding brand (agents.instacloud.com per the repo skill + agents.sh), so this looks sound — just flagging it as the one assumption riding on infra rather than code. No secrets, no auth weakening, no new dependencies. Both hosts are HTTPS.
• Scope / performance — no performance-relevant changes; scope is exemplary (one constant + comment, nothing extraneous). Comment style matches the existing inline-explanation convention in config.ts.

---

Verdict: approved

Zero Critical findings. The change is correct, minimal, and preserves behavior for existing installs. Suggestion/Information items above are non-blocking. (Informational verdict for the review bot — explicit GitHub approval remains a separate human action.)

[jwfing]

LGTM - approved.

[jwfing]

LGTM - approved.