slopus/happy · warning

⚠️ Invalid sandbox config - skipping. Error: ${error.message

Error message

⚠️ Invalid sandbox config - skipping. Error: ${error.message}

What it means

readSettings in happy-cli validates the persisted sandboxConfig against SandboxConfigSchema (zod). If the stored sandbox config fails schema validation, it logs this warning and drops sandboxConfig (sets it to undefined), so defaults are used instead of crashing. It is a non-fatal degradation of sandbox settings.

Source

Thrown at packages/happy-cli/src/persistence.ts:110

    // Check schema version (default to 1 if missing)
    const schemaVersion = raw.schemaVersion ?? 1;

    // Warn if schema version is newer than supported
    if (schemaVersion > SUPPORTED_SCHEMA_VERSION) {
      logger.warn(
        `⚠️ Settings schema v${schemaVersion} > supported v${SUPPORTED_SCHEMA_VERSION}. ` +
        'Update happy-cli for full functionality.'
      );
    }

    // Migrate if needed
    const migrated = migrateSettings(raw, schemaVersion);

    if (migrated.sandboxConfig !== undefined) {
      try {
        migrated.sandboxConfig = SandboxConfigSchema.parse(migrated.sandboxConfig);
      } catch (error: any) {
        logger.warn(`⚠️ Invalid sandbox config - skipping. Error: ${error.message}`);
        migrated.sandboxConfig = undefined;
      }
    }

    // Merge with defaults to ensure all required fields exist
    return { ...defaultSettings, ...migrated };
  } catch (error: any) {
    logger.warn(`Failed to read settings: ${error.message}`);
    // Return defaults on any error
    return { ...defaultSettings }
  }
}

export async function writeSettings(settings: Settings): Promise<void> {
  if (!existsSync(configuration.happyHomeDir)) {
    await mkdir(configuration.happyHomeDir, { recursive: true })
  }

View on GitHub (pinned to b824cd0a46)

Solutions

1. Open your happy settings file and fix sandboxConfig to match SandboxConfigSchema (correct types and required fields).
2. Simplest fix: delete the sandboxConfig key (or the whole file) and let happy regenerate defaults, then re-enable sandbox via happy's settings UI/command.
3. Check the zod error message in the warning — it names the exact failing field/path.
4. Upgrade or align happy CLI version if the file was written by a different version with a different sandbox schema.

Example fix

// before (~/.happy/settings.json)
{ "sandboxConfig": { "enabled": "yes", "profile": {} } }
// after
{ "sandboxConfig": { "enabled": true } }

import { SandboxConfigSchema } from '@/sandbox/schema'; // adjust to actual export
const raw = JSON.parse(fs.readFileSync(settingsPath, 'utf8'));
if (raw.sandboxConfig !== undefined) {
  const result = SandboxConfigSchema.safeParse(raw.sandboxConfig);
  if (!result.success) {
    console.warn('sandboxConfig invalid:', result.error.issues.map(i => `${i.path.join('.')}: ${i.message}`));
    delete raw.sandboxConfig; // let happy use defaults
  }
}

When it happens

Trigger: Settings file (~/.happy/settings.json or equivalent) contains a sandboxConfig object that fails SandboxConfigSchema.parse — e.g. wrong types, missing required fields, or an unknown/renamed field after a schema version bump, even after migrateSettings ran.

Common situations: Hand-edited settings.json with a typo (enabled: "true" instead of boolean), an old settings file written by a previous happy version whose sandbox schema has since changed, or config synced from another machine with a different happy version.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• No machine ID found in settings
• No machine ID found in settings
• No machine ID found in settings
• Failed to acquire settings lock after ${MAX_LOCK_ATTEMPTS *
• not_found

AI-assisted analysis of slopus/happy@b824cd0a46 (2026-08-31). Data as JSON: /api/errors/ded055bd2037193c. Report an issue: GitHub.