fix(install): configure and verify AuthKit application URLs

[nicknisi]

Summary

Follow-up to #243, which bundles @workos/skills@0.7.3. The skills explain the required application settings; this PR makes the installer create the sign-in route and configure supported settings itself, rather than relying on its restricted agent to run management commands.

• Include the shared AuthKit setup reference directly in the agent prompt. Keep the agent focused on app code and explicitly prohibit bypassing its shell restrictions.
• Require a dedicated Next.js /sign-in route using the SDK, separate from the callback. Include missing integration requirements in agent retries and fail validation instead of reporting incomplete code as installed.
• Configure Next.js callback, default Sign-out URI, and Initiate login URI through native installer code. Match the app client ID to a unique sandbox environment and its default application, preserve existing URLs/defaults, validate changes, and verify saved settings by reading them back.
• Preserve an existing homepage unless --homepage-url explicitly requests a change. Conflicting existing sign-out defaults or initiate-login URLs are left unchanged.
• Carry application setup results through the state machine into human and JSON completion output. Distinguish installed code, verified settings, and browser flows still needing tests.

Authentication and scope

• Automatic application URL setup requires an existing usable dashboard session; this step does not launch login.
• Unclaimed/API-key-only installs retain callback registration and receive explicit remaining setup instructions when dashboard configuration cannot be verified.
• Production environments and non-default applications are not configured automatically.
• Native application setup is Next.js-only. Shared prompt loading applies to other framework installers too.
• The Next.js post-agent validation still runs with --no-validate so the installer does not configure a missing route.
• This does not change logout or the installer's initial credential-selection behavior.

Verification

• bun run test: 2,807 tests passed across 162 files with published skills 0.7.3 installed.
• bun run typecheck and bun run lint passed.
• Formatting passed for the changed source/spec files and validation rules.
• bun run build passed.
• Compiled workos internal verify-assets --json passed and reported bundled skills 0.7.3.
• Tests cover client/environment targeting, preserving settings, rejected dry runs, concurrent edits, missing dashboard access, partial writes, read-back mismatches, route validation, and completion reporting.

End-to-end browser sign-in/sign-out and password-reset/invitation flows have not been verified for this PR. Unit tests use mocked dashboard responses; they do not prove a live dashboard configuration succeeds.

[greptile-apps]

Confidence Score: 3/5

The PR is not safe to merge until Pages Router handling and cross-environment credential targeting are corrected.

Findings

1.  Pages Router installs fail ▶
2.  Credentials target different environments ▶

Fix with agent prompt

### Issue 1
src/lib/agent-runner.ts:343-347
Pages Router is a supported and detected Next.js mode, but this instruction always tells the agent to create an App Router `/sign-in` route. The new validation rule also accepts only `{,src/}app/sign-in/route.*`, so a correct Pages Router implementation is rejected and the installation fails, or the agent must add an unwanted App Router tree. Please make the prompt and validation depend on the detected router and support the equivalent Pages Router route.

### Issue 2
src/lib/run-with-core.ts:394
The API key and Client ID are resolved independently and are never verified as a pair. For example, a run can combine an explicit API key with a project Client ID, or read the two values from different env files. The callback is then registered in the environment selected by the API key, while this call matches the Client ID through the dashboard session and can update a different sandbox application. This can distribute one installation's URL settings across two environments and add a callback to an unrelated application. Please verify the credential pair before either mutation or use one verified environment identity for all writes.

---

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

Summary

This PR adds native configuration and read-back verification for Next.js AuthKit application URLs, strengthens installation validation, and carries application setup status through interactive and headless completion output.

• Registers and verifies redirect, sign-out, initiate-login, and optional homepage URLs for matched sandbox applications.
• Adds a required Next.js sign-in route and makes ordinary validation failures block installation success.
• Extends completion events and summaries with verified or pending application-setup details.
• Two blocking integration issues remain: Pages Router projects are forced through App Router setup, and independently resolved API keys and Client IDs can direct mutations to different environments.

Diagram

sequenceDiagram
  participant I as Installer
  participant P as Project
  participant A as API-key environment
  participant D as Dashboard session
  participant B as Client-ID environment

  I->>P: Write credentials and callback to .env.local
  I->>A: Register callback using API key
  I->>P: Run agent and validate routes
  I->>P: Read Client ID and callback
  I->>D: Resolve sandbox by Client ID
  D->>B: Read application settings
  D->>B: Configure sign-out and initiate-login URLs
  D->>B: Add callback if missing
  D->>B: Read back and verify settings
  I-->>P: Emit verified or pending completion status

Loading

_{Reviews (1) · Last reviewed commit: "fix(install): configure and verify AuthK..."}

[greptile-apps]

Pages Router installs fail

Pages Router is a supported and detected Next.js mode, but this instruction always tells the agent to create an App Router /sign-in route. The new validation rule also accepts only {,src/}app/sign-in/route.*, so a correct Pages Router implementation is rejected and the installation fails, or the agent must add an unwanted App Router tree. Please make the prompt and validation depend on the detected router and support the equivalent Pages Router route.

Knowledge Base Used:

• Application installation workflows
• Installer orchestration and project mutation
• Agent and skills workflows

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/agent-runner.ts
Line: 343-347

Comment:
**Pages Router installs fail**

Pages Router is a supported and detected Next.js mode, but this instruction always tells the agent to create an App Router `/sign-in` route. The new validation rule also accepts only `{,src/}app/sign-in/route.*`, so a correct Pages Router implementation is rejected and the installation fails, or the agent must add an unwanted App Router tree. Please make the prompt and validation depend on the detected router and support the equivalent Pages Router route.

**Knowledge Base Used:**
- [Application installation workflows](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/cli/-/docs/application-installation.md)
- [Installer orchestration and project mutation](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/cli/-/docs/installer-orchestration.md)
- [Agent and skills workflows](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/cli/-/docs/agent-and-skills-workflows.md)

---

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

[greptile-apps]

Credentials target different environments

The API key and Client ID are resolved independently and are never verified as a pair. For example, a run can combine an explicit API key with a project Client ID, or read the two values from different env files. The callback is then registered in the environment selected by the API key, while this call matches the Client ID through the dashboard session and can update a different sandbox application. This can distribute one installation's URL settings across two environments and add a callback to an unrelated application. Please verify the credential pair before either mutation or use one verified environment identity for all writes.

Knowledge Base Used:

• Application installation workflows
• Authentication and configuration lifecycle
• Configuration and environment management

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/run-with-core.ts
Line: 394

Comment:
**Credentials target different environments**

The API key and Client ID are resolved independently and are never verified as a pair. For example, a run can combine an explicit API key with a project Client ID, or read the two values from different env files. The callback is then registered in the environment selected by the API key, while this call matches the Client ID through the dashboard session and can update a different sandbox application. This can distribute one installation's URL settings across two environments and add a callback to an unrelated application. Please verify the credential pair before either mutation or use one verified environment identity for all writes.

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

---

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