Error Report: 2026-04-12 (140 errors in last 24h)

[claude]

Summary

Critical filesystem permission errors affecting Windows and macOS users during eject command, with path corruption causing CLI crashes. Backend API errors continue at moderate volume. User validation errors are working as designed.

Metric	Value
Time range	last 24 hours
Total errors	140
CLI bugs	2
Backend issues	1
User errors (working as designed)	6
Unique users affected	53
Internal user occurrences	7

Errors requiring action

1. Filesystem permission errors during eject command — CLI bug

Error code	None (unclassified)
Occurrences	16 (0 internal)
Users affected	4
Command	eject, link
Platforms	Windows, macOS
PostHog	View in error tracking
Existing issue	None
Recurring	Yes (4+ days per previous reports)

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

EPERM: operation not permitted, scandir 'C:\Users\james\Application Data'
EPERM: operation not permitted, scandir '/Users/<redacted>/Desktop'

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: The CLI performs filesystem scanning operations that trigger permission errors when accessing restricted system directories. This occurs in the eject and link commands when the CLI scans for project files or validates paths:

// packages/cli/src/core/utils/fs.ts:124-127
export async function isDirEmpty(dir = process.cwd()) {
  const files = await readdir(dir);  // <-- EPERM occurs here
  return files.length === 0;
}

Suggested fix: In packages/cli/src/core/utils/fs.ts:125, wrap the readdir call in a try-catch block to handle permission errors gracefully and provide a clear error message when directory access is denied.

2. Path corruption in eject command causing mkdir failures — CLI bug

Error code	None (unclassified)
Occurrences	1 (0 internal)
Users affected	1
Command	eject
Platforms	Windows
PostHog	View in error tracking
Existing issue	Referenced in #473, #470, #467
Recurring	Yes (4+ days)

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

ENOENT: no such file or directory, mkdir 'C:\Users\I857833\nudg-copyC:\Users\I857833>'

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 Windows path resolution in the eject command flow:

// packages/cli/src/cli/commands/project/eject.ts:114
const resolvedPath = resolve(selectedPath);

// This corrupted path gets passed to:
// packages/cli/src/core/project/api.ts:85
await makeDirectory(projectPath);

// Which calls:
// packages/cli/src/core/utils/fs.ts:131
await mkdir(dirPath, { recursive: true });  // <-- ENOENT occurs here with corrupted path

The error shows paths getting incorrectly concatenated during Windows path resolution, resulting in invalid directory paths like C:\Users\I857833\nudg-copyC:\Users\I857833>.

Suggested fix: In packages/cli/src/cli/commands/project/eject.ts:114, add Windows-specific path normalization and validation before calling resolve() to prevent path corruption during directory resolution.

---

Backend issues (not CLI fixes)

Error	Occurrences	Users	Command	PostHog
Backend Platform app requirement	8	5	entities push, deploy	View

The CLI correctly reports 428 Precondition Required errors when Backend Platform features are accessed by incompatible app types.

User errors (working as designed)

Error	Occurrences	Users	Command	PostHog
No Base44 project found	47	14	link, deploy	View
Invalid input validation	40	13	deploy, eject, site deploy	View
Schema validation errors	14	4	functions deploy	View
App not configured	7	6	deploy	View
Project already linked	3	3	link	View
Deno dependency missing	3	3	exec	View
Authentication timeout	1	1	eject	View

All user errors show appropriate CLI validation with clear error messages and helpful guidance.

Recurring errors

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

Error	Days recurring	Existing issue	Tracked?
EPERM filesystem permission	4+ days	None	No
Path corruption in eject	4+ days	Referenced in #473, #470, #467	No dedicated issue
CONFIG_NOT_FOUND validation	5+ days	None	No (expected user error)
INVALID_INPUT validation	5+ days	None	No (expected user error)

The filesystem permission errors are an untracked recurring CLI bug affecting users across Windows and macOS.

Action items

1. [critical] packages/cli/src/core/utils/fs.ts:125 — Add try-catch around readdir call to handle EPERM errors gracefully with clear error messaging for permission-denied scenarios
2. [high] packages/cli/src/cli/commands/project/eject.ts:114 — Add Windows path normalization and validation before resolve() call to prevent path corruption during directory resolution
3. [low] Backend Platform app requirement errors (8 occurrences) — working as designed but may benefit from clearer error messaging