Make CLI project team optional with default

[sentry-junior]

sentry init and sentry project create still force team selection too often, even when the org has one sensible default. Until the upstream API provides an implied default, the CLI should make team optional and infer it locally.

Current behavior

sentry init

• Without an explicit target, multi-org accounts hit a flat org select first ("Which organization should the project be created in?" in packages/cli/src/lib/init/preflight.ts) with no create-org option and weak defaulting.
• Preflight then may prompt for a team ("Which team should own this project?") before project create/select is decided — team is only relevant when creating a project, and should come after that decision.
• New vs existing project is not auto-resolved from local signals (repo URL, cwd/git name, etc.); create-new is not an obvious top-level choice unless existing in-codebase Sentry metadata is already detected.

sentry project create

• Team is still a first-class create input via --team / team resolution (packages/cli/src/commands/project/create.ts, packages/cli/src/lib/resolve-team.js).
• Happy path still resolves a concrete team before posting to the team-scoped create endpoint (createProjectWithDsn → POST /teams/{org}/{team}/projects/).
• There is already a member fallback that posts to the org-scoped endpoint and lets the server auto-create a personal team-{username} (createProjectWithAutoTeam), but that is not the same as quietly defaulting to an existing org default team when the caller omits team.

Gap

• Flow order forces org/team picking before the real decision (new vs existing project), and does not use local repo signals to skip those steps.
• Team selection is noise for existing-project paths and still too prominent for headless create paths.
• Headless/agent project creation remains awkward because callers must understand teams even when they have no meaningful preference.
• Client-side inference is needed now; upstream API defaulting is tracked separately and may land later.

User stories

• As a new user running sentry init, I do not want an early team prompt before I even decide whether I am creating or selecting a project.
• As a headless/CLI user creating a project, I want to omit --team and still succeed.
• As a member of a single-team org, I want create flows to default to that team without prompting.
• As a member of a multi-team org, I still want an explicit team choice to win when supplied.
• As someone creating projects into a large existing org, I do not want a surprising personal team-{me} fork just because team was omitted.

Proposed solution

Reporter proposal for CLI-local behavior until (or unless) upstream API defines an implied default:

• Make team optional across create paths (sentry init create branch and sentry project create).
• When omitted, infer a deterministic default team (existing single accessible team / earliest active default-team behavior; do not invent a new personal team when a real default already exists).
• Keep explicit --team / explicit team selection unchanged.
• For init specifically: resolve org → decide new vs existing project from local signals → only then collect create-specific details, and skip team entirely when it can be inferred.
• Prefer create-new first only when there is no likely match; otherwise auto-select the match. Create-new vs select-existing should be top-level choices.
• Migrate to upstream implied-default API behavior when available.

Related:

• Upstream API: Make project-create team optional with default sentry#121490
• MCP client counterpart: Make create_project team optional sentry-mcp#1234
• Select overflow when option lists exceed terminal height: Select lists break when taller than terminal #1376

Requested by David Cramer.

--

View Junior Session [Sentry]

[sentry-junior]

Additional proposal for the team step:

• If the user has only one eligible team, skip team selection and default to that team.
• This may be better handled upstream in Sentry’s API: when project creation has exactly one eligible team, the API could default ownership when the team is omitted. We should evaluate that before making the CLI own the behavior.