fix(install): surface unclaimed environments honestly

[gjtorikian]

Summary

Three coupled fixes to the zero-auth install path, all from the same finding: the installer minted an environment, then described it in a way that sent the tester to the dashboard to reconcile a client ID that didn't match anything they had.

• Stop claiming credentials the user never provided. The credentialSource gate from feat!: consent-gated agent setup and flat CLI output #200 was correct, but the label feeding it was not. runWithCore backfills options.apiKey/clientId from the project's .env.local before the state machine starts — and that is exactly the path a freshly provisioned unclaimed environment takes, since provisioning writes that file from bin.ts first. So checkingCliFlags short-circuited and hardcoded 'cli', and the installer announced "Using the WorkOS credentials you provided" for credentials it had just minted itself. Credentials backfilled from a project env file are now labeled 'env'.
• Put the claim CTA where it will be read. workos profile claim was printed once, at provision time, then buried under scaffolding and the whole agent run. It now leads the completion box's next steps — first, because an unclaimed environment's credentials live only on the local machine, so a missed claim is the one step that cannot be recovered later. Resolved by reading config at completion (an environment claimed mid-install via the browser CTA is not told to claim itself) and gated on an exact credential match, so a leftover unclaimed profile can't name an environment this install never touched.
• Give unclaimed environments a name. POST /x/one-shot-environments returns no environmentId or environmentName, so profileEnvironmentLabel() had nothing to build from and the environment naming shipped in feat(install): name the environment in installer status lines #231/feat(install): show the whole team in the environment picker #232 could never reach an unclaimed environment — every status line degraded to "Using your active WorkOS environment", reading as though the CLI had picked up an environment the user already had. The authkitDomain the API already returns was being discarded; it is now persisted and rendered: "Using a new WorkOS environment created for this install (witty-rest-53.authkit.app)".
• Drive that copy from credentials:found, not just staging:success. Worth a reviewer's attention: the provisioned-unclaimed path never reaches staging resolution, so anything added only to the staging:success handler is dead code for the most common zero-auth install. Both paths are handled.
• Drop one more wrong-provenance claim. Found existing WorkOS credentials in .env.local no longer prints for credentials passed as --api-key/--client-id, which never came from that file.

Notes for reviewers

• credentials:found gained a payload (source, credentials); it was previously Record<string, never>.
• 13 tests added, including the negative cases: an unclaimed profile that did not supply the credentials, and provenance surviving the cli-flags short-circuit.
• Verified by unit tests and code trace — not by a live workos install, which would provision a real unclaimed environment and run the agent end to end.
• src/generated/runtime-deps-manifest.ts is untracked and not in .gitignore, unlike its two siblings on lines 25-26. Pre-existing and left alone here, but probably worth a follow-up.

[greptile-apps]

Greptile Summary

The PR corrects install-time credential provenance and improves the guidance shown for newly provisioned unclaimed environments.

• Preserves project-environment provenance through the credential short-circuit while avoiding false .env.local claims for explicit credentials.
• Persists and displays an unclaimed environment’s AuthKit domain.
• Adds a credential-matched claim step to the completion summary.
• Expands regression coverage for provenance, environment labeling, and claim guidance.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/lib/run-with-core.ts	Resolves credential provenance before machine startup and conditionally adds the claim command using the completion-time active environment.
src/lib/installer-core.ts	Carries credential source and values through the existing-credentials event without leaving the previous mixed-provenance issue outstanding.
src/lib/adapters/cli-adapter.ts	Renders source-aware credential messages and identifies matching unclaimed environments by their persisted AuthKit domain.
src/lib/unclaimed-env-provision.ts	Persists the AuthKit domain alongside the unclaimed environment’s existing claim data.
src/lib/completion-data.ts	Places an applicable environment-claim action before the normal framework completion steps.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Resolve command and project credentials] --> B{User supplied either credential?}
  B -->|No, project credentials found| C[Source: env]
  B -->|Yes| D[Preserve caller source]
  C --> E[Installer credential short-circuit]
  D --> E
  E --> F{Credentials match active unclaimed environment?}
  F -->|Yes| G[Show newly created environment label]
  F -->|No| H[Use source-appropriate status output]
  G --> I[Run installation]
  H --> I
  I --> J{Matching environment still unclaimed?}
  J -->|Yes| K[Lead completion steps with profile claim]
  J -->|No| L[Render normal completion steps]

Loading

_{Reviews (2): Last reviewed commit: "fix(install): stop labeling mixed creden..." | Re-trigger Greptile}