fix(install): verify claim status before setting a default homepage

[nicknisi]

Problem

A local profile can still say an environment is unclaimed after someone claims it elsewhere. The installer then treats its default homepage write as safe and can replace a homepage configured in the dashboard.

Change

Ports the previously staged follow-up onto current main after #250:

• Reuse the existing claim-nonce API to confirm the matching environment is still unclaimed before an implicit REST homepage write.
• Make the shared helper async and await it in both the post-agent API-only setup and the older auto-configuration path.
• Check the expected client ID when available, in addition to the stored API key match.
• Leave the homepage unchanged when the environment is claimed or claim status cannot be established. Callback/CORS registration still proceeds.
• Keep explicit --homepage-url overrides independent of the claim check.

The probe creates a claim nonce but does not claim the environment. It inherits the existing request timeout. This is a best-effort preflight, not an atomic guard against an environment being claimed concurrently with the homepage write. Dashboard-session setup is unchanged.

Validation

• Regression tests failed before the implementation: 14 failures.
• Focused tests: 126 passed.
• Full suite: 3,129 passed on rerun. The initial run hit the existing skills-repair sibling-protection flake; it passed in isolation and on the full rerun without changes.
• Typecheck, build, lint, and diff checks passed.
• Independent review found no blockers.
• No live unclaimed-environment provisioning or claim/write test performed.

Only four files change; no dependency or CI changes.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Changes when the installer sets a default homepage URL.

The PR appears safe to merge, with non-blocking endpoint-consistency and setup-latency issues worth addressing.

Findings

1.  Claim check uses another host ▶
2.  Claim check delays other settings ▶

Fix with agent prompt

### Issue 1
src/lib/workos-management.ts:162
If the active profile has a custom endpoint or `WORKOS_API_URL` is set, this nonce request goes to that host, while the homepage PUT still goes to `https://api.workos.com`. A failed check can leave the homepage unset even when the write endpoint is available, and a successful check does not confirm claim status at the host receiving the write. Use the same API host for both requests.

### Issue 2
src/lib/workos-management.ts:261
This path waits for the nonce request before starting redirect and CORS registration or showing setup progress. If the request stalls, its 30-second timeout delays both settings, although claim status is needed only for the homepage decision. Start the additive settings independently of the check.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR adds a live claim-nonce check before implicit homepage writes in both installer paths, while preserving explicit homepage overrides and skipping writes when claim status is unavailable.

• Under an endpoint override, the check and homepage write can use different API hosts.
• In the legacy path, a slow check delays redirect and CORS registration.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Installer URL setup] --> B{Explicit homepage?}
  B -->|Yes| W[Write homepage]
  B -->|No| C{Stored unclaimed profile matches?}
  C -->|No| S[Leave homepage unchanged]
  C -->|Yes| D[Request claim nonce]
  D -->|Nonce confirms unclaimed| W
  D -->|Claimed or unavailable| S

Loading

_{Reviews (1) · Last reviewed commit: "fix(install): verify claim status before..."}

[greptile-apps]

Claim check uses another host If the active profile has a custom endpoint or WORKOS_API_URL is set, this nonce request goes to that host, while the homepage PUT still goes to https://api.workos.com. A failed check can leave the homepage unset even when the write endpoint is available, and a successful check does not confirm claim status at the host receiving the write. Use the same API host for both requests.

Knowledge Base Used: Authentication and configuration lifecycle

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/workos-management.ts
Line: 162

Comment:
**Claim check uses another host** If the active profile has a custom endpoint or `WORKOS_API_URL` is set, this nonce request goes to that host, while the homepage PUT still goes to `https://api.workos.com`. A failed check can leave the homepage unset even when the write endpoint is available, and a successful check does not confirm claim status at the host receiving the write. Use the same API host for both requests.

**Knowledge Base Used:** [Authentication and configuration lifecycle](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/cli/-/docs/authentication-and-configuration.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Claim check delays other settings This path waits for the nonce request before starting redirect and CORS registration or showing setup progress. If the request stalls, its 30-second timeout delays both settings, although claim status is needed only for the homepage decision. Start the additive settings independently of the check.

Knowledge Base Used: Application installation workflows

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/workos-management.ts
Line: 261

Comment:
**Claim check delays other settings** This path waits for the nonce request before starting redirect and CORS registration or showing setup progress. If the request stalls, its 30-second timeout delays both settings, although claim status is needed only for the homepage decision. Start the additive settings independently of the check.

**Knowledge Base Used:** [Application installation workflows](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/cli/-/docs/application-installation.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.