Error Report: 2026-02-20 (123 errors in last 24h)

[claude]

Summary

No critical CLI bugs found. Most errors are user configuration issues (running commands outside project directories, missing dependencies) or backend deployment timeouts. Two areas need attention: EPIPE errors during authentication and authentication timeouts.

Metric	Value
Time range	last 24 hours
Total errors	123
CLI bugs	1
Backend issues	3
User errors (working as designed)	5
Unique users affected	58
Internal user occurrences	18

Errors requiring action

1. Authentication flow broken pipe errors — CLI bug

Error code	None
Occurrences	10 (0 internal)
Users affected	8
Command	whoami
Platforms	Windows
PostHog	View in error tracking
Existing issue	None
Recurring	No

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

Error: EPIPE: broken pipe, write

Stack trace: (only show frames from src/ — skip generic entry points like runCLI, parseAsync)

at login (src/cli/commands/auth/login-flow.ts:104:16)
at waitForAuthentication (src/cli/commands/auth/login-flow.ts:45:4)

Root cause: (what you found in the code — include a code snippet)

// src/cli/commands/auth/login-flow.ts:45
try {
  await runTask(
    "Waiting for authentication...",
    async () => {
      await pWaitFor(
        async () => {
          const result = await getTokenFromDeviceCode(deviceCode);
          if (result !== null) {
            tokenResponse = result;
            return true;
          }
          return false;
        },
        {
          interval: interval * 1000,
          timeout: expiresIn * 1000,
        },
      );
    },
    {
      successMessage: "Authentication completed!",
      errorMessage: "Authentication failed",
    },
  );
} catch (error) {
  if (error instanceof Error && error.message.includes("timed out")) {
    throw new Error("Authentication timed out. Please try again.");
  }
  throw error;
}

The EPIPE error occurs during the authentication polling process, likely when the user cancels the process and the stdout stream becomes unavailable, but the CLI continues trying to write status updates.

Suggested fix: Add EPIPE error handling in the login flow to gracefully handle cancelled authentication attempts and avoid throwing unhandled pipe errors.

---

Backend issues (not CLI fixes)

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

Error	Occurrences	Users	Command	PostHog
Function deployment timeouts	23	16	functions deploy	link
Backend Platform availability errors	8	6	deploy, entities push	link
Site deployment errors	2	2	deploy	link

These are not CLI bugs but may need backend team attention. Function deployment timeouts ("wait_for_deployment timed out after 90 seconds") and Backend Platform availability errors ("only available for Backend Platform apps") suggest server-side infrastructure issues.

User errors (working as designed)

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

Error	Occurrences	Users	Command	PostHog
No project found (CONFIG_NOT_FOUND)	34	18	link, functions deploy	link
Project already linked (CONFIG_EXISTS)	14	7	link	link
Invalid user input	13	3	Various	link
Schema validation errors	10	4	eject, types generate	link
Missing app configuration	5	5	deploy	link

The CONFIG_NOT_FOUND error has the highest volume (34 occurrences) but is working as designed - users are running commands outside of Base44 project directories. The CLI correctly guides them to run base44 create or base44 link.

Recurring errors

No previous error reports found to compare against.

Action items

Numbered list of concrete next steps, most important first:

1. [medium] src/cli/commands/auth/login-flow.ts:45 — Add EPIPE error handling in the authentication flow to gracefully handle cancelled operations without throwing unhandled pipe errors
2. [low] Monitor function deployment timeout patterns to identify if this is a consistent backend issue requiring infrastructure attention
3. [low] Consider improving error message for missing output directory to be more actionable (currently FILE_NOT_FOUND, could suggest build step)

[kfirstri]

@claude

1. update the daily-error-reporter.yml to also include informatiom about schemaValidationErros, i want to make sure we don't have issues with the CLI schemas and that it's only user's errors.
   2.[medium] src/cli/commands/auth/login-flow.ts:45 — Add EPIPE error handling in the authentication flow to gracefully handle cancelled operations without throwing unhandled pipe errors

[claude]

Claude finished @kfirstri's task in 2m 46s —— View job • claude/issue-280-20260220-0821 • Create PR ➔

---

Tasks

• Gather context: read relevant files
• Fix EPIPE error handling in src/cli/commands/auth/login-flow.ts
• daily-error-report.yml schema validation changes — see below

---

1. EPIPE fix — done

In src/cli/commands/auth/login-flow.ts, the waitForAuthentication catch block now handles EPIPE errors explicitly. When the user closes their terminal or cancels while the spinner is writing, the process exits cleanly via CLIExitError(0) instead of surfacing a confusing broken-pipe error:

} catch (error) {
  if (error instanceof Error) {
    if (error.message.includes("timed out")) {
      throw new Error("Authentication timed out. Please try again.");
    }
    // EPIPE: user closed the terminal or cancelled while we were writing spinner
    // updates. Exit cleanly rather than propagating an unhandled broken-pipe error.
    if ((error as NodeJS.ErrnoException).code === "EPIPE") {
      throw new CLIExitError(0);
    }
  }
  throw error;
}

---

2. daily-error-report.yml — cannot modify (workflow file permissions)

I'm unable to modify .github/workflows/ files — GitHub App permissions don't allow workflow changes. You'll need to apply this manually.

What to add — in the Generate report with Claude step, inside the ## Step 4: Classify every error section of the prompt, add the following paragraph after the existing is_user_error bullet points:

**Schema validation errors** (`error_code = SCHEMA_INVALID`): Pay special attention to these.
The `SchemaValidationError` class is thrown in two distinct situations:
- **User files** (e.g., `entities/*.jsonc`, project config files) — these are `is_user_error = true` and working as designed.
- **Internal API response validation** (e.g., Zod parsing of API responses in `src/core/`) — these would be `is_user_error = false` and indicate a CLI bug where our schema is out of sync with the backend.

For each `SCHEMA_INVALID` error group, read the stack trace to determine which path triggered it. If frames point to `src/core/` schema parsing (not user-facing files), classify it as a CLI bug and include the offending Zod schema and the mismatched field. This is the primary signal for whether schema errors are user issues or CLI bugs.

This gives the report generator the context to distinguish user-caused schema errors from internal schema mismatches.

---