[logger] Invalid LOG_LEVEL '${process.env.LOG_LEVEL}'. Valid

Error message

[logger] Invalid LOG_LEVEL '${process.env.LOG_LEVEL}'. Valid levels: ${[...VALID_LEVELS].join(', ')}. Falling back to 'info'.

What it means

The logger reads LOG_LEVEL at initialization (getInitialLevel). If the env var is set but not one of the valid level names, it warns via console (the logger isn't configured yet) and falls back to 'info' instead of crashing.

Source

Thrown at packages/paths/src/logger.ts:43

import pino from 'pino';
import type { Logger } from 'pino';
import pretty from 'pino-pretty';

export type { Logger } from 'pino';

// 'silent' is Pino's built-in level that disables all output. The CLI uses it
// in --json mode to keep stdout to exactly the JSON payload.
const VALID_LEVELS = new Set(['fatal', 'error', 'warn', 'info', 'debug', 'trace', 'silent']);

function getInitialLevel(): string {
  const envLevel = process.env.LOG_LEVEL?.toLowerCase();
  if (envLevel) {
    if (VALID_LEVELS.has(envLevel)) {
      return envLevel;
    }
    // Warn via console since the logger itself isn't configured yet
    console.warn(
      `[logger] Invalid LOG_LEVEL '${process.env.LOG_LEVEL}'. ` +
        `Valid levels: ${[...VALID_LEVELS].join(', ')}. Falling back to 'info'.`
    );
  }
  return 'info';
}

/**
 * Build the root Pino logger.
 *
 * Uses `pino-pretty` as a **destination stream** (not a worker-thread transport)
 * when stdout is a TTY and NODE_ENV !== 'production'. Running pino-pretty as a
 * destination stream keeps the formatter on the main thread, which avoids the
 * `require.resolve('pino-pretty')` lookup that crashes inside Bun's `/$bunfs/`
 * virtual filesystem in compiled binaries (see GitHub issue #960 / #979).
 *
 * The same code path runs in dev and compiled binaries — no environment
 * detection required.

View on GitHub (pinned to 0773b97458)

Solutions

Set LOG_LEVEL to a valid level: debug, info, warn, error (check VALID_LEVELS in packages/paths/src/logger.ts).
Remove the LOG_LEVEL env var to use the 'info' default.
Fix casing/whitespace: the check lowercases the value, so 'DEBUG' works but 'debug ' (trailing space) does not.

Example fix

// before
LOG_LEVEL=verbose
// console: [logger] Invalid LOG_LEVEL 'verbose'. Valid levels: ... Falling back to 'info'.
// after
LOG_LEVEL=debug

Defensive patterns

Strategy: validation

Validate before calling

const VALID = new Set(['debug','info','warn','error']);
const lvl = process.env.LOG_LEVEL?.toLowerCase().trim();
if (lvl && !VALID.has(lvl)) console.warn(`LOG_LEVEL '${process.env.LOG_LEVEL}' invalid; using 'info'`);

Type guard

function isValidLogLevel(v: string | undefined): v is 'debug'|'info'|'warn'|'error' {
  return !!v && ['debug','info','warn','error'].includes(v.toLowerCase().trim());
}

Prevention

Restrict LOG_LEVEL values in .env files and CI to the documented set.
Normalize (lowercase/trim) env values before export.
Add a startup smoke check that asserts the configured level is accepted.

When it happens

Trigger: Setting LOG_LEVEL to an unrecognized value such as 'verbose', 'warn ', 'DEBUG' typos like 'logg', or a numeric level ('3').

Common situations: Copying LOG_LEVEL from another library that accepts different names; typos or stray whitespace/case issues; CI env files exporting an invalid default.

Related errors

AI-assisted analysis of coleam00/Archon@0773b97458 (2026-09-01). Data as JSON: /api/errors/203468406b8d965a. Report an issue: GitHub.