merge: resolve api-client.ts conflict with main's modular refactor

Port deleteProject into src/lib/api/projects.ts and re-export from
the barrel file, aligning with main's split of api-client into
domain modules under src/lib/api/.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: betegon

AGENTS.md

@@ -628,6 +628,9 @@ mock.module("./some-module", () => ({
 
 ### Architecture
 
+<!-- lore:019ce2be-39f1-7ad9-a4c5-4506b62f689c -->
+* **api-client.ts split into domain modules under src/lib/api/**: The original monolithic \`src/lib/api-client.ts\` (1,977 lines) was split into 12 focused domain modules under \`src/lib/api/\`: infrastructure.ts (shared helpers, types, raw requests), organizations.ts, projects.ts, teams.ts, repositories.ts, issues.ts, events.ts, traces.ts, logs.ts, seer.ts, trials.ts, users.ts. The original \`api-client.ts\` was converted to a ~100-line barrel re-export file preserving all existing import paths. The \`biome.jsonc\` override for \`noBarrelFile\` already includes \`api-client.ts\`. When adding new API functions, place them in the appropriate domain module under \`src/lib/api/\`, not in the barrel file.
+
 <!-- lore:019cb8ea-c6f0-75d8-bda7-e32b4e217f92 -->
 * **CLI telemetry DSN is public write-only — safe to embed in install script**: The CLI's Sentry DSN (\`SENTRY\_CLI\_DSN\` in \`src/lib/constants.ts\`) is a public write-only ingest key already baked into every binary. Safe to hardcode in install scripts. Opt-out: \`SENTRY\_CLI\_NO\_TELEMETRY=1\`.
 
@@ -659,15 +662,9 @@ mock.module("./some-module", () => ({
 <!-- lore:019c8ab6-d119-7365-9359-98ecf464b704 -->
 * **@sentry/api SDK passes Request object to custom fetch — headers lost on Node.js**: @sentry/api SDK calls \`\_fetch(request)\` with no init object. In \`authenticatedFetch\`, \`init\` is undefined so \`prepareHeaders\` creates empty headers — on Node.js this strips Content-Type (HTTP 415). Fix: fall back to \`input.headers\` when \`init\` is undefined. Use \`unwrapPaginatedResult\` (not \`unwrapResult\`) to access the Response's Link header for pagination. \`per\_page\` is not in SDK types; cast query to pass it at runtime.
 
-<!-- lore:019cc484-f0e1-7016-a851-177fb9ad2cc4 -->
-* **AGENTS.md must be excluded from markdown linters**: AGENTS.md is auto-managed by lore and uses \`\*\` list markers and long lines that violate typical remark-lint rules (unordered-list-marker-style, maximum-line-length). When a project uses remark with \`--frail\` (warnings become errors), AGENTS.md will fail CI. Fix: add \`AGENTS.md\` to \`.remarkignore\`. This applies to any lore-managed project with markdown linting.
-
 <!-- lore:019c9e98-7af4-7e25-95f4-fc06f7abf564 -->
 * **Bun binary build requires SENTRY\_CLIENT\_ID env var**: The build script (\`script/bundle.ts\`) requires \`SENTRY\_CLIENT\_ID\` environment variable and exits with code 1 if missing. When building locally, use \`bun run --env-file=.env.local build\` or set the env var explicitly. The binary build (\`bun run build\`) also needs it. Without it you get: \`Error: SENTRY\_CLIENT\_ID environment variable is required.\`
 
-<!-- lore:019cc40e-e56e-71e9-bc5d-545f97df732b -->
-* **Consola prompt cancel returns truthy Symbol, not false**: When a user cancels a \`consola\` / \`@clack/prompts\` confirmation prompt (Ctrl+C), the return value is \`Symbol(clack:cancel)\`, not \`false\`. Since Symbols are truthy in JavaScript, checking \`!confirmed\` will be \`false\` and the code falls through as if the user confirmed. Fix: use \`confirmed !== true\` (strict equality) instead of \`!confirmed\` to correctly handle cancel, false, and any other non-true values.
-
 <!-- lore:019c9776-e3dd-7632-88b8-358a19506218 -->
 * **GitHub immutable releases prevent rolling nightly tag pattern**: getsentry/cli has immutable GitHub releases — assets can't be modified and tags can NEVER be reused. Nightly builds publish to GHCR with versioned tags like \`nightly-0.14.0-dev.1772661724\`, not GitHub Releases or npm. \`fetchManifest()\` throws \`UpgradeError("network\_error")\` for both network failures and non-200 — callers must check message for HTTP 404/403. Craft with no \`preReleaseCommand\` silently skips \`bump-version.sh\` if only target is \`github\`.
 
@@ -680,16 +677,13 @@ mock.module("./some-module", () => ({
 <!-- lore:019c9741-d78e-73b1-87c2-e360ef6c7475 -->
 * **useTestConfigDir without isolateProjectRoot causes DSN scanning of repo tree**: \`useTestConfigDir()\` creates temp dirs under \`.test-tmp/\` in the repo tree. Without \`{ isolateProjectRoot: true }\`, \`findProjectRoot\` walks up and finds the repo's \`.git\`, causing DSN detection to scan real source code and trigger network calls against test mocks (timeouts). Always pass \`isolateProjectRoot: true\` when tests exercise \`resolveOrg\`, \`detectDsn\`, or \`findProjectRoot\`.
 
-<!-- lore:019cc303-e397-75b9-9762-6f6ad108f50a -->
-* **Zod z.coerce.number() converts null to 0 silently**: Zod gotchas in this codebase: (1) \`z.coerce.number()\` passes input through \`Number()\`, so \`null\` silently becomes \`0\`. Be aware if \`null\` vs \`0\` distinction matters. (2) Zod v4 \`.default({})\` short-circuits — it returns the default value without parsing through inner schema defaults. So \`.object({ enabled: z.boolean().default(true) }).default({})\` returns \`{}\`, not \`{ enabled: true }\`. Fix: provide fully-populated default objects. This affected nested config sections in src/config.ts during the v3→v4 upgrade.
-
 ### Pattern
 
 <!-- lore:019c972c-9f11-7c0d-96ce-3f8cc2641175 -->
 * **Org-scoped SDK calls follow getOrgSdkConfig + unwrapResult pattern**: All org-scoped API calls in src/lib/api-client.ts: (1) call \`getOrgSdkConfig(orgSlug)\` for regional URL + SDK config, (2) spread into SDK function: \`{ ...config, path: { organization\_id\_or\_slug: orgSlug, ... } }\`, (3) pass to \`unwrapResult(result, errorContext)\`. Shared helpers \`resolveAllTargets\`/\`resolveOrgAndProject\` must NOT call \`fetchProjectId\` — commands that need it enrich targets themselves.
 
 <!-- lore:5ac4e219-ea1f-41cb-8e97-7e946f5848c0 -->
-* **PR workflow: wait for Seer and Cursor BugBot before resolving**: After pushing a PR in getsentry/cli, CI includes Seer Code Review and Cursor Bugbot as advisory checks (~2-3 min). They may not trigger on draft PRs — use \`gh pr ready\` first. Workflow: push → \`gh pr checks \<PR> --watch\` → check for bot review comments → fix → repeat. Use GraphQL \`reviewThreads\` query with \`isResolved\` filter to find unresolved comments. Reply to bot comments after fixing.
+* **PR workflow: wait for Seer and Cursor BugBot before resolving**: After pushing a PR in the getsentry/cli repo, the CI pipeline includes Seer Code Review and Cursor Bugbot as advisory checks. Both typically take 2-3 minutes but may not trigger on draft PRs — only ready-for-review PRs reliably get bot reviews. The workflow is: push → wait for all CI (including npm build jobs which test the actual bundle) → check for inline review comments from Seer/BugBot → fix if needed → repeat. Use \`gh pr checks \<PR> --watch\` to monitor. Review comments are fetched via \`gh api repos/OWNER/REPO/pulls/NUM/comments\` and \`gh api repos/OWNER/REPO/pulls/NUM/reviews\`.
 
 <!-- lore:019cb162-d3ad-7b05-ab4f-f87892d517a6 -->
 * **Shared pagination infrastructure: buildPaginationContextKey and parseCursorFlag**: List commands with cursor pagination use \`buildPaginationContextKey(type, identifier, flags)\` for composite context keys and \`parseCursorFlag(value)\` accepting \`"last"\` magic value. Critical: \`resolveCursor()\` must be called inside the \`org-all\` override closure, not before \`dispatchOrgScopedList\` — otherwise cursor validation errors fire before the correct mode-specific error.

DEVELOPMENT.md

@@ -67,10 +67,11 @@ When creating your Sentry OAuth application:
 
 ## Environment Variables
 
-| Variable           | Description                          | Default              |
-| ------------------ | ------------------------------------ | -------------------- |
-| `SENTRY_CLIENT_ID` | Sentry OAuth app client ID           | (required)           |
-| `SENTRY_URL`       | Sentry instance URL (for self-hosted)| `https://sentry.io`  |
+| Variable           | Description                                           | Default              |
+| ------------------ | ----------------------------------------------------- | -------------------- |
+| `SENTRY_CLIENT_ID` | Sentry OAuth app client ID                            | (required)           |
+| `SENTRY_HOST`      | Sentry instance URL (for self-hosted, takes precedence) | `https://sentry.io`  |
+| `SENTRY_URL`       | Alias for `SENTRY_HOST`                               | `https://sentry.io`  |
 
 ## Building
 

biome.jsonc

@@ -56,7 +56,9 @@
     },
     {
       // db/index.ts exports db connection utilities - not a barrel file but triggers the rule
-      "includes": ["src/lib/db/index.ts"],
+      // api-client.ts is a barrel that re-exports from src/lib/api/ domain modules
+      // to preserve the existing import path for all consumers
+      "includes": ["src/lib/db/index.ts", "src/lib/api-client.ts"],
       "linter": {
         "rules": {
           "performance": {

docs/src/content/docs/commands/auth.md

@@ -84,18 +84,18 @@ sentry auth refresh
 
 This is typically handled automatically when tokens expire.
 
-## Configuration
+## Credential Storage
 
-Credentials are stored in `~/.sentry/config.json` with restricted file permissions (mode 600).
+Credentials are stored in a SQLite database at `~/.sentry/cli.db` with restricted file permissions (mode 600).
 
-**Config structure:**
+Use `sentry auth token` to retrieve your current access token, or `sentry auth status` to check authentication state.
 
-```json
-{
-  "auth": {
-    "token": "...",
-    "refreshToken": "...",
-    "expiresAt": "2024-12-31T00:00:00Z"
-  }
-}
-```
+### Environment Variable Precedence
+
+The CLI checks for auth tokens in the following order, using the first one found:
+
+1. `SENTRY_AUTH_TOKEN` environment variable (legacy)
+2. `SENTRY_TOKEN` environment variable
+3. The stored token in the SQLite database
+
+When a token comes from an environment variable, the CLI skips expiry checks and automatic refresh.

docs/src/content/docs/configuration.md

@@ -7,16 +7,22 @@ The Sentry CLI can be configured through environment variables and a local datab
 
 ## Environment Variables
 
-### `SENTRY_URL`
+### `SENTRY_HOST`
 
 Base URL of your Sentry instance. **Only needed for [self-hosted Sentry](./self-hosted/).** SaaS users (sentry.io) should not set this.
 
 ```bash
-export SENTRY_URL=https://sentry.example.com
+export SENTRY_HOST=https://sentry.example.com
 ```
 
 When set, all API requests (including OAuth login) are directed to this URL instead of `https://sentry.io`. The CLI also sets this automatically when you pass a self-hosted Sentry URL as a command argument.
 
+`SENTRY_HOST` takes precedence over `SENTRY_URL`. Both work identically — use whichever you prefer.
+
+### `SENTRY_URL`
+
+Alias for `SENTRY_HOST`. If both are set, `SENTRY_HOST` takes precedence.
+
 ### `SENTRY_ORG`
 
 Default organization slug. Skips organization auto-detection.
@@ -138,9 +144,11 @@ The `sentry api` command also uses `--verbose` to show full HTTP request/respons
 
 ## Credential Storage
 
-Credentials are stored in a SQLite database at `~/.sentry/` (or the path set by `SENTRY_CONFIG_DIR`) with restricted file permissions (mode 600) for security. The database also caches:
+We store credentials and caches in a SQLite database (`cli.db`) inside the config directory (`~/.sentry/` by default, overridable via `SENTRY_CONFIG_DIR`). The database file and its WAL side-files are created with restricted permissions (mode 600) so that only the current user can read them. The database also caches:
 
 - Organization and project defaults
 - DSN resolution results
 - Region URL mappings
 - Project aliases (for monorepo support)
+
+See [Credential Storage](./commands/auth/#credential-storage) in the auth command docs for more details.

docs/src/content/docs/self-hosted.md

@@ -3,10 +3,10 @@ title: Self-Hosted Sentry
 description: Using the Sentry CLI with a self-hosted Sentry instance
 ---
 
-The CLI works with self-hosted Sentry instances. Set the `SENTRY_URL` environment variable to point at your instance:
+The CLI works with self-hosted Sentry instances. Set the `SENTRY_HOST` (or `SENTRY_URL`) environment variable to point at your instance:
 
 ```bash
-export SENTRY_URL=https://sentry.example.com
+export SENTRY_HOST=https://sentry.example.com
 ```
 
 ## Authenticating
@@ -27,14 +27,14 @@ The OAuth device flow requires **Sentry 26.1.0 or later** and a public OAuth app
 Pass your instance URL and the client ID:
 
 ```bash
-SENTRY_URL=https://sentry.example.com SENTRY_CLIENT_ID=your-client-id sentry auth login
+SENTRY_HOST=https://sentry.example.com SENTRY_CLIENT_ID=your-client-id sentry auth login
 ```
 
 :::tip
 You can export both variables in your shell profile so every CLI invocation picks them up:
 
 ```bash
-export SENTRY_URL=https://sentry.example.com
+export SENTRY_HOST=https://sentry.example.com
 export SENTRY_CLIENT_ID=your-client-id
 ```
 :::
@@ -48,7 +48,7 @@ If your instance is on an older version or you prefer not to create an OAuth app
 3. Pass it to the CLI:
 
 ```bash
-SENTRY_URL=https://sentry.example.com sentry auth login --token YOUR_TOKEN
+SENTRY_HOST=https://sentry.example.com sentry auth login --token YOUR_TOKEN
 ```
 
 ## After Login
@@ -66,7 +66,8 @@ If you pass a self-hosted Sentry URL as a command argument (e.g., an issue or ev
 
 | Variable | Description |
 |----------|-------------|
-| `SENTRY_URL` | Base URL of your Sentry instance |
+| `SENTRY_HOST` | Base URL of your Sentry instance (takes precedence over `SENTRY_URL`) |
+| `SENTRY_URL` | Alias for `SENTRY_HOST` |
 | `SENTRY_CLIENT_ID` | Client ID of your public OAuth application |
 | `SENTRY_ORG` | Default organization slug |
 | `SENTRY_PROJECT` | Default project slug (supports `org/project` format) |

plugins/sentry-cli/skills/sentry-cli/SKILL.md

@@ -44,6 +44,7 @@ Authenticate with Sentry
 **Flags:**
 - `--token <value> - Authenticate using an API token instead of OAuth`
 - `--timeout <value> - Timeout for OAuth flow in seconds (default: 900) - (default: "900")`
+- `--force - Re-authenticate without prompting`
 
 **Examples:**
 

src/commands/auth/login.ts

@@ -1,3 +1,4 @@
+import { isatty } from "node:tty";
 import type { SentryContext } from "../../context.js";
 import { getCurrentUser, getUserRegions } from "../../lib/api-client.js";
 import { buildCommand, numberParser } from "../../lib/command.js";
@@ -9,7 +10,7 @@ import {
   setAuthToken,
 } from "../../lib/db/auth.js";
 import { getDbPath } from "../../lib/db/index.js";
-import { setUserInfo } from "../../lib/db/user.js";
+import { getUserInfo, setUserInfo } from "../../lib/db/user.js";
 import { AuthError } from "../../lib/errors.js";
 import { formatUserIdentity } from "../../lib/formatters/human.js";
 import { runInteractiveLogin } from "../../lib/interactive-login.js";
@@ -21,8 +22,58 @@ const log = logger.withTag("auth.login");
 type LoginFlags = {
   readonly token?: string;
   readonly timeout: number;
+  readonly force: boolean;
 };
 
+/**
+ * Handle the case where the user is already authenticated.
+ *
+ * Returns `true` if the login flow should proceed (credentials cleared),
+ * or `false` if the command should exit early.
+ *
+ * - Env-var auth: always blocks re-auth (user must unset the var).
+ * - `--force`: clears auth silently and proceeds.
+ * - Interactive TTY: prompts user to confirm re-authentication.
+ * - Non-interactive without `--force`: prints a message and blocks.
+ */
+async function handleExistingAuth(force: boolean): Promise<boolean> {
+  if (isEnvTokenActive()) {
+    const envVar = getActiveEnvVarName();
+    log.info(
+      `Authentication is provided via ${envVar} environment variable. ` +
+        `Unset ${envVar} to use OAuth-based login instead.`
+    );
+    return false;
+  }
+
+  if (!force) {
+    // Non-interactive (piped, CI): print message and block
+    if (!isatty(0)) {
+      log.info(
+        "You are already authenticated. Use '--force' or 'sentry auth logout' first to re-authenticate."
+      );
+      return false;
+    }
+
+    // Interactive TTY: prompt user to confirm re-authentication
+    const userInfo = getUserInfo();
+    const identity = userInfo ? formatUserIdentity(userInfo) : "current user";
+    const confirmed = await log.prompt(
+      `Already authenticated as ${identity}. Re-authenticate?`,
+      { type: "confirm", initial: false }
+    );
+
+    // Symbol(clack:cancel) is truthy — strict equality check
+    if (confirmed !== true) {
+      return false;
+    }
+  }
+
+  // Clear existing credentials and caches before re-authenticating
+  await clearAuth();
+  return true;
+}
+
 export const loginCommand = buildCommand({
   docs: {
     brief: "Authenticate with Sentry",
@@ -46,23 +97,20 @@ export const loginCommand = buildCommand({
         // Stricli requires string defaults (raw CLI input); numberParser converts to number
         default: "900",
       },
+      force: {
+        kind: "boolean",
+        brief: "Re-authenticate without prompting",
+        default: false,
+      },
     },
   },
   async func(this: SentryContext, flags: LoginFlags): Promise<void> {
-    // Check if already authenticated
+    // Check if already authenticated and handle re-authentication
     if (await isAuthenticated()) {
-      if (isEnvTokenActive()) {
-        const envVar = getActiveEnvVarName();
-        log.info(
-          `Authentication is provided via ${envVar} environment variable. ` +
-            `Unset ${envVar} to use OAuth-based login instead.`
-        );
-      } else {
-        log.info(
-          "You are already authenticated. Use 'sentry auth logout' first to re-authenticate."
-        );
+      const shouldProceed = await handleExistingAuth(flags.force);
+      if (!shouldProceed) {
+        return;
       }
-      return;
     }
 
     // Token-based authentication

src/commands/auth/logout.ts

@@ -30,7 +30,7 @@ export const logoutCommand = buildCommand({
   docs: {
     brief: "Log out of Sentry",
     fullDescription:
-      "Remove stored authentication credentials from the configuration file.",
+      "Remove stored authentication credentials from the local database.",
   },
   output: { json: true, human: formatLogoutResult },
   parameters: {