Error Report: 2026-04-08 (159 errors in last 24h)

[claude]

Summary

One critical CLI bug with path corruption in eject command affects users on macOS. Multiple backend API issues continue including timeouts and app resolution failures. User validation errors show healthy patterns with appropriate CLI messaging.

Metric	Value
Time range	last 24 hours
Total errors	159
CLI bugs	1
Backend issues	3
User errors (working as designed)	7
Unique users affected	63
Internal user occurrences	1

Errors requiring action

1. Path corruption in eject command causing permission denied — CLI bug

Error code	None (unclassified)
Occurrences	3 (0 internal)
Users affected	3
Command	eject
Platforms	macOS
PostHog	View in error tracking
Existing issue	None
Recurring	Yes (3+ days)

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

EACCES: permission denied, mkdir '/Users/swim-shift'

Stack trace: (only CLI stack trace frames)

at runCLI (packages/cli/src/cli/index.ts:59:4)
at Command.parseAsync (commander/lib/command.js:1243:4)

Root cause: Path corruption occurs during eject command when resolving target directories:

// packages/cli/src/core/utils/fs.ts:129-133
export async function makeDirectory(dirPath: string): Promise<void> {
  if (!(await pathExists(dirPath))) {
    await mkdir(dirPath, { recursive: true }); // <-- EACCES occurs here
  }
}

The error shows the CLI attempting to create directory '/Users/swim-shift' instead of a proper path like /Users/<username>/swim-shift. This path corruption happens in the eject command flow:

// packages/cli/src/cli/commands/project/eject.ts:114
const resolvedPath = resolve(selectedPath);
// ... later calls downloadProject which calls makeDirectory(projectPath)

Suggested fix: In packages/cli/src/core/utils/fs.ts:131, add path validation to detect invalid directory paths and provide clear error messaging when path resolution fails during eject operations.

2. Unclassified fetch failures in auth operations — needs investigation

Error code	None (unclassified)
Occurrences	9 (1 internal)
Users affected	7
Command	whoami
Platforms	Unknown
PostHog	None (no issue_id)
Existing issue	None
Recurring	No

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

fetch failed

Stack trace: (no stack trace captured due to unclassified error)

(Stack trace not available)

Root cause: Network errors during authentication operations are not being properly classified and wrapped with appropriate error codes. This suggests either connectivity issues or API endpoint problems affecting auth-related commands.

Suggested fix: Review error handling in authentication flows to ensure network failures are properly classified with appropriate error codes and user-friendly messaging.

---

Backend issues (not CLI fixes)

Error	Occurrences	Users	Command	PostHog
API timeout during site deployment	8	8	deploy	link
App not found (404)	19	9	secrets list	link
OAuth expired token	3	3	whoami	link

API timeouts: Deployment operations timing out with Request timed out: POST https://app.base44.com/api/apps/.../deploy-dist. These appear to be large site deployments hitting backend timeout limits.

App not found: API calls receiving 404 responses indicating app IDs in users' configuration files no longer exist in the backend system.

OAuth token expiry: Backend returning 400 status with "expired_token" errors during authentication flows.

User errors (working as designed)

Error	Occurrences	Users	Command	PostHog
No Base44 project found	42	19	link	link
Missing required parameters	38	19	link	link
Project already linked	10	6	link	link
App not configured	9	7	dev	link
Invalid project schema	7	6	dev	link
Deno dependency missing	7	5	dev	link
Authentication timeout	6	6	link	link

All user error volumes are within expected ranges. The CLI correctly validates input and provides appropriate error messages with helpful guidance.

Recurring errors

Based on previous daily reports, these errors have appeared multiple days:

Error	Days recurring	Existing issue	Tracked?
CONFIG_NOT_FOUND validation	5+ days	Referenced in #466, #465, #464, #463, #462	No dedicated issue
Path corruption (eject)	3+ days	Referenced in #466, #465, #464	No dedicated issue
API timeout during deployment	3+ days	Referenced in #466, #465	No dedicated issue
Authentication timeout	5+ days	Referenced in #466, #465, #464, #463, #462	No dedicated issue

The path corruption issue is an untracked recurring CLI bug affecting multiple users across several days.

Action items

1. [critical] packages/cli/src/core/utils/fs.ts:131 — Add path validation before mkdir operations to detect corrupted paths like '/Users/swim-shift' and provide clear error messaging
2. [medium] Review authentication error classification to ensure network failures get proper error codes rather than appearing as unclassified "fetch failed"
3. [low] Backend team should investigate deployment timeout patterns (8 occurrences) and app resolution 404 errors (19 occurrences)