Changed from hardcoded config schema to a flexible one for YAML-Imports

[Zirkonium88]

Summary

Fixes #72 and #73.

The admin panel validates imported YAML configs and individual field edits using configSchema from librechat-data-provider. This schema uses z.nativeEnum() for fields like endpoints.agents.capabilities, which rejects values not present in the bundled enum at build time. When LibreChat adds new enum values upstream (e.g. subagents, skills, or any future addition to OCR strategies, file sources, etc.), the admin panel rejects otherwise valid configs — blocking users from using new features even with correct YAML from the changelog.

This PR makes validation lenient for enum mismatches generically across all config fields: if the only validation errors are invalid_enum_value, the config is accepted as-is. Structural and type errors still block import. This keeps the admin panel forward-compatible with newer LibreChat versions without requiring a synchronized release.

Change Type

• Bug fix (non-breaking change which fixes an issue)

Testing

1. Create a librechat.yaml with agent capabilities including values unknown to the current enum:

   version: 1.3.12
   endpoints:
     agents:
       capabilities:
         - 'execute_code'
         - 'file_search'
         - 'web_search'
         - 'artifacts'
         - 'subagents'
         - 'skills'
         - 'tools'
         - 'chain'
         - 'ocr'

2. Import via the admin panel config editor
3. Before this fix: Config validation failed error listing Invalid enum value for subagents and skills
4. After this fix: Config imports successfully, all values preserved

Also verified:

• Configs with actual structural errors (wrong types, missing required fields) still fail validation
• Invalid MCP transport types still rejected (invalid_union, not invalid_enum_value)
• All 160+ existing unit tests pass
• 2 new tests added covering the forward-compatibility behavior
• Deployed patched version and imported YAML and clicked the config

Test Configuration:

SESSION_SECRET=test-secret-at-least-32-chars-long npx vitest run src/server/config.test.ts

• librechat-data-provider: 0.8.505+
• LibreChat config version: 1.3.12

Checklist

• My code adheres to this project's style guidelines
• I have performed a self-review of my own code
• I have commented in any complex areas of my code
• My changes do not introduce new warnings
• I have written tests demonstrating that my changes are effective or that my feature works
• Local unit tests pass with my changes

---

Note

Medium Risk
Changes central config import and per-field validation paths; incorrect bypass logic could accept bad configs, but scope is limited to string-only enum mismatches and is covered by new tests.

Overview
Makes admin config validation tolerate unknown string enum values from newer LibreChat releases, so YAML imports and field edits are not blocked when librechat-data-provider’s bundled z.nativeEnum() lags upstream (e.g. new agent capabilities).

validateFieldValue now ignores invalid_enum_value issues when received is a string; structural/type problems and non-string enum failures (e.g. numbers in enum arrays) still fail.

parseImportedYaml uses the same rule for full-document validation: if enum string mismatches are the only errors, it runs parseWithEnumBypass—strip those paths, safeParse for defaults/transforms/stripping, then restore the original enum values—so imports succeed with values preserved. Mixed validation errors still return Config validation failed with paths/messages.

^{Reviewed by Cursor Bugbot for commit 1bba590. Bugbot is set up for automated code reviews on this repo. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[Zirkonium88]

This is an intentional tradeoff. The risk of typos slipping through is minimal because:

1. LibreChat validates at runtime — the admin panel is an editing layer, not the enforcement layer. Invalid capabilities are rejected when LibreChat actually loads the config.
2. Only invalid_enum_value is bypassed — typos in non-enum fields (wrong types, invalid URLs, malformed objects) still fail immediately.
3. The alternative is worse — without this, every LibreChat release that adds a new enum value blocks the admin panel entirely until a synchronized release ships. This is the exact production issue reported in Admin panel is not allowing config import - no lockstep with LibreChat config version #72.

The panel could additionally show a non-blocking warning ("unknown values: subagents, skills — verify these are valid for your LibreChat version") but that's a UX enhancement for a follow-up, not a blocker.

[danny-avila]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a33b74751c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject non-string native enum values before bypassing

For z.nativeEnum-backed string enums such as endpoints.agents.capabilities, Zod v3 reports numeric inputs (for example capabilities: [123]) as invalid_enum_value rather than as a type error, because native enums accept string/number before membership checking. This nonEnumIssues.length === 0 branch—and the same isOnlyEnumErrors check below for YAML imports—therefore accepts and persists numeric enum entries as “forward-compatible” values, even though future capabilities are still strings. Please verify the offending value type or path before suppressing the enum issue.

Useful? React with 👍 / 👎.

[Zirkonium88]

Adressed in 1bba590

[chatgpt-codex-connector]

Preserve schema parsing when accepting enum-only imports

When an import contains an unknown enum value plus a misspelled or unsupported config key, configSchema.safeParse fails only on the enum because normal Zod object parsing strips unknown keys instead of reporting them; this branch then returns the original rawConfig rather than a schema-parsed object. That means the otherwise-stripped keys, and any skipped defaults/transforms, are passed on to the import flow only in the enum-forward-compatibility path. Please keep the parsed/sanitized shape when suppressing enum errors instead of returning the raw YAML object.

Useful? React with 👍 / 👎.

[Zirkonium88]

Adressed in 1bba590

[chatgpt-codex-connector]

To use Codex here, create a Codex account and connect to github.