Files
opencode/packages
Kit Langton 18f3b31f1c fix(config): drop malformed top-level fields instead of crashing the load
Reported by Ben Matthews on Discord against v1.14.45: a `skills:` field
shaped as an array (rather than the schema's `{paths?, urls?}` object)
caused the entire config load to fail with ConfigInvalidError, the
server returned 500, and the desktop app couldn't start.

Per Kit:
> for all of these things that we load from the user's computer, they
> should be kind of tolerant. We can have warnings that we log
> somewhere, but Jesus. It shouldn't break opencode.

This makes `ConfigParse.effectSchema` field-tolerant:

- Unknown top-level keys are stripped (with a warning log) instead of
  throwing `unrecognized_keys`.
- Top-level fields whose value fails decoding are dropped (with a
  warning log naming the field + the issue summary), the rest of the
  config decodes normally.
- Root-level errors (e.g. data is not an object at all) and post-strip
  failures still throw the original `InvalidError` so we don't silently
  swallow truly broken configs.

Three new tests cover the reported shape (skills as array), unknown
keys, and multi-bad-field cases. Two existing tests that asserted the
strict-throw behavior were updated to the new tolerant contract.

Pre-fix: opencode unstartable for users with malformed configs.
Post-fix: opencode starts, the bad field is ignored, the user sees a
warning in the log naming what was dropped.
2026-05-09 20:37:44 -04:00
..
2026-05-10 00:07:24 +00:00
2026-05-10 00:07:24 +00:00
2026-01-21 14:36:21 -06:00
2026-05-10 00:07:24 +00:00
2026-05-10 00:07:24 +00:00
2026-05-10 00:07:24 +00:00
2026-05-10 00:07:24 +00:00
2026-05-10 00:07:24 +00:00
2026-05-10 00:07:24 +00:00