Error Report: 2026-05-22 (265 errors in last 24h)

[claude]

Summary

User validation errors dominate with appropriate CLI messaging. Backend API restrictions and authentication issues continue as expected patterns. One unclassified error with file system permissions identified.

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

Errors requiring action

1. File system permission error lacks proper CLI error classification — CLI bug

Error code	null (missing)
Occurrences	5 (0 internal)
Users affected	1
Command	dashboard open
Platforms	Windows
PostHog	None (no issue_id)
Existing issue	None
Recurring	No

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

EPERM: operation not permitted, scandir 'C:\Users\<redacted>\Cookies'

Stack trace: (missing frames due to minimal error data)

No stack trace available (unclassified error)

Root cause: The dashboard open command uses the open npm package to launch the browser:

// packages/cli/src/cli/commands/dashboard/open.ts:12
await open(dashboardUrl);

When the open package tries to access browser data on Windows, it can hit permission errors when scanning certain directories like the Cookies folder. This raw filesystem error bubbles up without proper CLI error classification, resulting in null error_code and is_user_error values in telemetry.

Suggested fix: In packages/cli/src/cli/commands/dashboard/open.ts:12, wrap the open() call in a try-catch block and throw an appropriate CLI error class (like SystemError) when filesystem permission errors occur, providing better error messaging and proper classification.

---

Backend issues (not CLI fixes)

1. App access restrictions and platform limitations — Backend business rules

Error	Occurrences	Users	Command	PostHog
Private app access (403)	59	32	agents pull	View in error tracking
Platform restrictions (428)	29	16	deploy, entities push	View in error tracking
Rate limit exceeded (429)	10	7	eject	View in error tracking

403 Error: (from PostHog)

Error fetching agents: This app is private, You do not have access to this app
Request failed with status code 403 Forbidden: GET https://app.base44.com/api/apps/<redacted>/agent-configs

428 Error: (from PostHog)

Error syncing entities: This endpoint is only available for Backend Platform apps
Request failed with status code 428 Precondition Required: PUT https://app.base44.com/api/apps/<redacted>/entity-schemas

429 Error: (from PostHog)

Request failed with status code 429 Too Many Requests: GET https://app.base44.com/api/apps/<redacted>/eject
Error downloading project: Rate limit exceeded

Backend correctly enforces business rules for app access, feature availability by app type, and API rate limits. CLI properly reports these via standard API error handling.

2. Server response schema validation failures — Backend data format issue

Error	Occurrences	Users	Command	PostHog
Response validation	6	4	functions list	View in error tracking

Error: (from PostHog)

Invalid response from server:
✖ Invalid input
  → at functions[3].automations[0]

The backend API is returning function objects with invalid automations fields that don't match the expected Zod schema. This suggests the backend response format has changed or contains malformed data.

3. Entity deletion conflicts — Backend data integrity

Error	Occurrences	Users	Command	PostHog
Entity schema deletion	18	10	deploy	View in error tracking

Error: (from PostHog)

Error syncing entities: Cannot delete entity schema for 'HomeConfig': it has existing records
Request failed with status code 428 Precondition Required: PUT https://app.base44.com/api/apps/<redacted>/entity-schemas

Backend correctly prevents deletion of entity schemas that have existing data records, maintaining data integrity.

---

User errors (working as designed)

Error	Occurrences	Users	Command	PostHog
Function deployment validation	53	22	functions deploy	View in error tracking
Entity schema validation	24	8	functions deploy, dev, eject	[Multiple error groups]
Project not found validation	34	20	link, exec	View in error tracking
Project already linked	18	11	link	View in error tracking
Authentication timeout	17	17	whoami, login	View in error tracking
Deno dependency validation	16	13	exec, dev	View in error tracking
App configuration missing	13	10	functions list	View in error tracking
Non-interactive mode validation	11	8	deploy, link	[Multiple error groups]
Config already exists	8	3	eject	View in error tracking
No input provided	4	4	exec	View in error tracking

INVALID_INPUT analysis: From packages/cli/src/cli/commands/functions/deploy.ts:65-69, the CLI validates incompatible flag usage:

// packages/cli/src/cli/commands/functions/deploy.ts:65-69
if (options.force && names.length > 0) {
  throw new InvalidInputError(
    "--force cannot be used when specifying function names",
  );
}

This provides clear guidance preventing users from combining conflicting options.

SCHEMA_INVALID analysis: Entity validation from packages/cli/src/core/errors.ts:245-247 provides specific field-level guidance:

// packages/cli/src/core/errors.ts:245-247
const message = filePath
  ? `${context} in ${filePath}:\n${z.prettifyError(zodError)}`
  : `${context}:\n${z.prettifyError(zodError)}`;

This produces detailed validation messages that help users fix their entity configurations.

CONFIG_NOT_FOUND analysis: From packages/cli/src/core/project/app-config.ts:48-50, when no project is found:

// packages/cli/src/core/project/app-config.ts:48-50
throw new ConfigNotFoundError(
  "No Base44 project found. Run this command from a project directory with a config.jsonc file.",
);

CONFIG_EXISTS analysis: Users trying to link already-linked projects get appropriate validation preventing overwrites: "Project is already linked. An .app.jsonc file with the appId already exists."

AUTH_EXPIRED analysis: Authentication timeout handling provides clear guidance: "Authentication timed out. Please try again."

DEPENDENCY_NOT_FOUND analysis: The CLI properly validates Deno installation and provides clear guidance: "Deno is required to run scripts with exec" when the dependency is missing.

CONFIG_INVALID analysis: App configuration validation provides guidance: "App not configured. Create a .app.jsonc file or run 'base44 link' to link this project."

INVALID_INPUT (exec) analysis: From packages/cli/src/cli/commands/exec.ts:23-34, the exec command validates stdin input:

// packages/cli/src/cli/commands/exec.ts:23-34
const noInputError = new InvalidInputError(
  "No input provided. Pipe a script to stdin.",
  {
    hints: [
      { message: "File:  cat ./script.ts | base44 exec" },
      { message: 'Eval:  echo "..." | base44 exec' },
    ],
  },
);

This provides actionable examples for proper usage.

Recurring errors

Based on previous daily reports (#526, #525, #524, #523, #522), these errors continue from multiple days:

Error	Days recurring	Existing issue	Tracked?
CONFIG_NOT_FOUND validation	22+ days	Referenced in all previous reports	Yes (expected user error)
Backend Platform restrictions	14+ days	Referenced in recent reports	Yes (backend business rules)
Function deployment validation	3+ days	Referenced in recent reports	Yes (expected user error)
Schema validation errors	22+ days	Referenced in all previous reports	Yes (expected user error)
Authentication timeout	22+ days	Referenced in all previous reports	Yes (expected timeout)
Dependency validation	22+ days	Referenced in all previous reports	Yes (expected user error)
Project linking validation	22+ days	Referenced in all previous reports	Yes (expected user error)
App configuration errors	22+ days	Referenced in all previous reports	Yes (expected user error)
Server response validation	4+ days	Referenced in #526, #525, #523	No (backend investigation needed)

The server response schema validation failures are an untracked recurring backend issue affecting multiple users over several days.

Action items

1. [low] packages/cli/src/cli/commands/dashboard/open.ts:12 — Wrap the open() call in a try-catch block and throw appropriate CLI error class when filesystem permission errors occur to ensure proper error classification instead of allowing raw EPERM errors to bubble up unclassified
2. [medium] Backend team investigation needed for server response schema validation failures where function automations fields don't match expected Zod schema - indicates backend response format changes or malformed data affecting 4+ users over 4 days
3. [low] Backend Platform restrictions (403/428/429 errors) represent correct business rules and API enforcement - users receive appropriate error messages
4. [low] All user validation errors provide clear guidance and actionable next steps for resolution - no CLI changes needed