fix(cli): classify auth failures by type, not message text

[posthog-eu]

Summary

• Who is hurt: the team, not users. A message reword two hours after PR fix(cli): stop error-tracking expected user errors and per-version fingerprints #2885 silently broke the substring filter meant to keep CLI auth failures out of error tracking, so expected user-configuration failures are captured as crashes again and bury real CLI crashes.
• Root cause: classification by free-text message. isExpectedUserError matched message.includes(marker), and commit fea2c5739 inserted the word "Capgo" into the thrown message — the substring stopped matching, no test failed. A second message (RBAC "Insufficient permissions for app …") was never covered by any marker and interpolated the app id, so it fingerprinted one issue per app.
• Fix — classify by type, not text: convert both throw sites to CliUserError, which shouldCapturePosthogException skips by type. This is the durable pattern already used in cli/src/channel/currentBundle.ts. No future reword can break it.

Throw site	Before	After
cli/src/utils.ts — resolveUserIdFromApiKey	throw new Error('Capgo authentication failed: …')	throw new CliUserError('Capgo authentication failed: …')
cli/src/api/app.ts — checkAppExistsAndHasPermissionOrgErr	throw new Error(\Insufficient permissions for app ${appid}. … ${requiredPermissionKey}`)`	throw new CliUserError('Insufficient permissions for app. …', { appId, requiredPermission })

• The user-facing log.error messages are unchanged — they still print the full detail (including app id and permission key). Only the thrown error type changes.
• The RBAC app id and permission key move into CliUserError context, so error tracking maps every app to one issue instead of one per app (the same rule CliUserError documents for dynamic identifiers).
• The marker list in cli/src/posthog.ts stays as a fallback for backend-supplied code strings and the 401 status check.

Test plan

• bun test/test-posthog-exception.mjs — added assertions that both new CliUserError throws are skipped by shouldCapturePosthogException, and that two different app ids produce the same message (one issue, not one per app).
• bun run lint:ox and bun run typecheck pass.

Screenshots

Checklist

• My code follows the code style of this project and passes
  bun run lint:backend && bun run lint.
• My change requires a change to the documentation.
• I have updated the documentation
  accordingly.
• My change has adequate E2E test coverage.
• I have tested my code manually, and I have provided steps how to reproduce
  my tests

Agent context

• The signal that opened the report came from CLI 7.125.4, an old npx-cached build that predates every fix and will keep sending the original message regardless of what ships. That is handled separately by suppressing pre-8.33.1 versions in error tracking — no code change reaches builds already in npx caches.
• Overlaps with fix(cli): stop reporting backend upload failures as bad API keys #2955 (fix(cli): stop reporting backend upload failures as bad API keys), which edits the same two files for a different cause. This change is additive; rebase on fix(cli): stop reporting backend upload failures as bad API keys #2955 if it lands first.

---

Created with PostHog Desktop from this inbox report.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[codspeed-hq]

Merging this PR will not alter performance

✅ 43 untouched benchmarks
⏩ 2 skipped benchmarks¹

---

_{Comparing posthog-self-driving/fixcli-classify-auth-failures-by-type-77efc6 (d3735c6) with main (bac918f)}

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud