fix(init): default to creation and share team resolution

[betegon]

Summary

Make sentry init creation-first while still reusing a concrete local match:

• resolve the effective organization first, then constrain every project signal to it
• use the CLI-wide resolver for DSN, local .sentryclirc, exact git remote, cwd, and project-root signals
• automatically reuse only one complete, unambiguous match
• otherwise make Create a new Sentry project the first/default action
• load the potentially large project list only after Use an existing Sentry project is selected
• never resolve or prompt for a team when an existing project is reused

Use one capability-based team and endpoint policy for both sentry init and sentry project create:

• preserve an explicit --team
• filter to teams where the caller has effective Team Admin access
• interactive, one eligible team: show + Create a new team first and Use #team directly
• interactive, multiple eligible teams: show + Create a new team and Select an existing team as top-level actions; the second prompt contains teams only
• never append create-new to the end of a potentially long team selector
• non-interactive, one eligible team: use it automatically
• non-interactive, multiple eligible teams: require --team; never silently choose the first
• no eligible team or create-new selected: use the organization onboarding route when policy allows it, otherwise apply the restricted-organization Team Admin checks
• resolve the team once for multi-project batches and reuse it

The shared project-creation routing preserves explicit and interactive choices, diagnoses stale OAuth grants as missing team:admin, and lets scope-bearing 403s reach the CLI-wide reauthorization flow. Cancelling the nested init prompt now remains a clean wizard cancellation.

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 env-token execution do not start OAuth.

Scope

Closes #1375.

The terminal-height overflow problem remains separate in #1376 and is intentionally not changed here.

Test plan

• focused team/project/init suite: 9 files, 271 tests passed
• pnpm exec tsc --noEmit
• pnpm run lint — 975 files checked
• docs and SDK generation produce no uncommitted changes
• full unit suite reproduces only the known environment-dependent failures in timezone assertions and bash completion simulation

[cursor]

Default org blocks local matches

High Severity

resolvePreferredOrg uses resolveOrg, which returns an account-wide default org before any DSN signal. That sticky org is then passed as organizationFilter into codebase-mode project resolution, so a concrete local DSN or git match in another org is dropped and init proceeds create-first under the wrong organization.

Additional Locations (2)

• packages/cli/src/lib/resolve-target.ts#L1993-L2010
• packages/cli/src/lib/init/preflight.ts#L226-L231

 

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

[sentry]

Bug: When project creation is disabled by organization policy, the code incorrectly throws a team:admin scope error, triggering a misleading OAuth flow instead of showing the policy message.
_{Severity: HIGH}

Suggested Fix

In project-creation.ts, when the fallback error is due to an organization policy (isMemberCreationDisabled403(fallbackError) is true), the original fallbackError should be re-thrown. This will allow upstream error handlers to correctly identify the policy restriction and display the appropriate message to the user, rather than incorrectly converting it to a scope issue.

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/project-creation.ts#L187

Potential issue: When team-scoped project creation fails and the subsequent org-scoped
fallback also fails due to an organization policy disabling member project creation, the
code incorrectly handles this. Instead of propagating the policy error, it calls
`buildTeamAdminAuthorizationError` at `project-creation.ts:187`. This converts the
policy error into a `team:admin` scope authorization error. As a result, the CLI's error
handling logic bypasses the check for the policy message and instead triggers an
unnecessary OAuth re-authorization flow, which cannot fix a policy-based restriction,
confusing the user.

Also affects:

• packages/cli/src/lib/project-creation.ts:157~159

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

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

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

[cursor]

Filter plus unresolved DSNs skips inference

Medium Severity

After applying organizationFilter, the DSN branch returns early when skippedSelfHosted is set even if filtered targets is empty. That prevents the intended fallthrough to codebase-name inference for the selected org whenever any detected DSN failed to resolve, despite the nearby debug message describing that fallthrough.

 

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

[cursor]

Create hint ignores ambiguous matches

Low Severity

resolveImplicitProjectSelection always recommends create with the hint that no matching project was found. That path also runs when multiple exact matches exist in the chosen org, so the hint can be false and push users toward creating a duplicate.

 

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