feat(init): resolve projects and improve existing setups

[betegon]

Summary

• default sentry init to creating a new project unless repository signals resolve one existing project unambiguously
• share project and team creation policy across sentry init and sentry project create, including Team Admin handling and safe non-interactive behavior
• discover monorepo targets using repository, package, framework, and deployment signals before resolving the Sentry project
• surface an existing setup as an explicit improvement flow, while keeping use-or-create-another-project as a separate action
• explain that improving a setup upgrades it and can add more Sentry features
• preserve detected existing features as the initial feature selection and remain compatible with older server protocol versions
• open the Files panel at the top of the analysis tree with conventional scrolling
• keep create-new-team above team choices instead of hiding it at the end of a long selector

OAuth companion

#1373 adds team:admin to the standard OAuth scope set for new grants and refreshes eligible existing interactive grants once after a scope-specific 403. Unattended, JSON/non-interactive, dry-run, and effective environment-token execution do not start OAuth.

Test plan

• pnpm typecheck
• focused preflight and Ink UI suite: 3 files, 79 tests
• scoped Biome validation clean, apart from the repository known non-failing large-type internal diagnostic
• docs and SDK generation leave the worktree clean
• full unit suite was also run; 9 unrelated baseline failures remain in completion shell simulation, timezone-sensitive time ranges, and one resolver mock

Closes #1375.

The terminal-height overflow remains separate in #1376.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cli	Ready	Preview	Aug 22, 2026 1:53pm

[sentry]

Bug: The resolveExistingProjectChoice and findAvailableProjectSlug functions don't handle API errors from tryGetExistingProjectData, causing the wizard to crash on transient network or server issues.
_{Severity: HIGH}

Suggested Fix

Wrap the calls to tryGetExistingProjectData within resolveExistingProjectChoice and findAvailableProjectSlug in try...catch blocks. The catch block should handle the ApiError gracefully, perhaps by logging the error and returning a failure state or re-throwing a more specific WizardError that the top-level runner can interpret, rather than letting the wizard crash.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: packages/cli/src/lib/init/preflight.ts#L356

Potential issue: The functions `resolveExistingProjectChoice` and
`findAvailableProjectSlug` both call `tryGetExistingProjectData` without handling
potential non-404 API errors. `tryGetExistingProjectData` is designed to throw an
`ApiError` for issues like network failures, timeouts, or 5xx server errors. Because
these calls are not wrapped in a `try...catch` block, any such transient API error will
propagate up the call stack. This causes the `sentry init` wizard to crash with an
unhandled exception instead of gracefully handling the failure, for example, by retrying
or informing the user. This can happen during explicit project selection or when the
wizard is automatically searching for an available project slug.

Also affects:

• packages/cli/src/lib/init/preflight.ts:569~575

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f39ffa1. Configure here.}

[cursor]

Unattended improve gate too strict

High Severity

--yes and --dry-run call assertImprovementSupported whenever a local Sentry setup is detected, so a setup service that does not advertise improve-existing-setup aborts the run. Interactive mode already recovers by offering another project, and a failed or capability-less health check sets the same flag to false, so unattended init on repos with existing Sentry can fail even when the wizard would otherwise continue.

Additional Locations (2)

• packages/cli/src/lib/init/preflight.ts#L212-L214
• packages/cli/src/lib/init/readiness.ts#L59-L83

 

^{Reviewed by Cursor Bugbot for commit f39ffa1. Configure here.}