Error Report: 2026-03-12 (131 errors in last 24h)

[claude]

Summary

Authentication timeout classification bug persists from yesterday (recurring 6+ days). Backend deployment failures with "unusable" response dominate new errors. Windows create command shows concerning path resolution bug attempting to write to system32 directories.

Metric	Value
Time range	last 24 hours
Total errors	131
CLI bugs	1
Backend issues	42
User errors (working as designed)	85
Needs investigation	3
Unique users affected	41
Internal user occurrences	8

Errors requiring action

1. Authentication timeout lacks error classification — CLI bug

Error code	None (unclassified)
Occurrences	12 (1 internal)
Users affected	10
Command	whoami, deploy, login
Platforms	Multiple
PostHog	View in error tracking
Existing issue	#403 (yesterday's report)
Recurring	Yes (6+ days)

Error: (from PostHog — the actual error message users see)

Error: Authentication timed out. Please try again.

Stack trace: (only showing frames from packages/cli/src/)

at waitForAuthentication (packages/cli/src/cli/commands/auth/login-flow.ts:71)

Root cause: The authentication timeout throws a generic Error without proper classification:

// packages/cli/src/cli/commands/auth/login-flow.ts:69-73
} catch (error) {
  if (error instanceof Error && error.message.includes("timed out")) {
    throw new Error("Authentication timed out. Please try again.");
  }
  throw error;
}

This timeout occurs when the OAuth2 device code expires (line 60: timeout: expiresIn * 1000). The generic Error lacks proper classification for telemetry tracking, causing error_code: null and is_user_error: null in PostHog.

Suggested fix: In packages/cli/src/cli/commands/auth/login-flow.ts:71, replace throw new Error(...) with a proper error class that sets appropriate error code and classification.

---

2. Windows create command writes to system32 — needs investigation

Error code	None (filesystem error)
Occurrences	3 (0 internal)
Users affected	3
Command	create, eject
Platforms	Windows
PostHog	View in error tracking
Existing issue	None
Recurring	No

Error: (from PostHog — the actual error message users see)

Failed to process template file ".nvmrc": EPERM: operation not permitted, mkdir 'C:\Windows\system32\system-32'

Stack trace: (only showing frames from packages/cli/src/)

at renderTemplate (packages/cli/src/core/project/template.ts:78)
at createProjectFiles (packages/cli/src/core/project/create.ts:48)

Root cause: Path resolution bug in template rendering. The writeFile and copyFile functions attempt to create directories via mkdir(dir, { recursive: true }):

// packages/cli/src/core/utils/fs.ts:31-34
const dir = dirname(filePath);
if (!(await pathExists(dir))) {
  await mkdir(dir, { recursive: true });
}

The file path somehow resolves to C:\Windows\system32\<project-name> instead of the intended project directory. This occurs in renderTemplate when calculating destFilePath = join(destPath, destFile).

Suggested fix: Add path validation in packages/cli/src/core/project/template.ts to ensure destPath is not a system directory before file operations.

---

Backend issues (not CLI fixes)

Brief table of errors caused by the backend/server, not the CLI:

Error	Occurrences	Users	Command	PostHog
"unusable" deploy response	27	13	deploy	link
Function deployment errors	8	5	functions deploy	link
"You must be logged in" sync error	3	2	deploy	link
OAuth "expired_token" error	1	1	whoami	link
Backend Platform endpoint error	1	1	agents push	link
EPIPE write error	1	1	whoami	link

User errors (working as designed)

Brief table of expected user errors where the CLI validation is correct:

Error	Occurrences	Users	Command	PostHog
CONFIG_NOT_FOUND (wrong directory)	19	16	link, dev, deploy, etc.	link
SCHEMA_INVALID (malformed configs)	8	6	eject, functions deploy	link
CONFIG_EXISTS (already linked)	4	4	link	link
INVALID_INPUT (project not found)	4	3	link, eject	link
Eject build failure (missing main.jsx)	2	1	eject	link

Recurring errors

Error	Days recurring	Existing issue	Tracked?
Authentication timeout classification bug	6+ days	#403	yes

The authentication timeout error continues to lack proper error classification, affecting telemetry accuracy and error categorization. This was flagged in yesterday's report but remains unfixed.

Action items

Numbered list of concrete next steps, most important first:

1. [high] packages/cli/src/cli/commands/auth/login-flow.ts:71 — Replace generic Error with proper error class (e.g., AuthenticationTimeoutError) that sets error_code and is_user_error for telemetry classification

2. [medium] packages/cli/src/core/project/template.ts — Add path validation before file operations to prevent writing to Windows system directories. Validate destPath is not under system directories like C:\Windows\system32

3. [low] Monitor backend deployment "unusable" responses — this represents 20% of all errors but requires backend team investigation, not CLI changes