Use Zod at config boundaries and audit validation

[khodam666]

Context

The OpenKhodam config store currently normalizes parsed JSON manually. That is fine for PR #26, but as config grows we should use schema validation where it matters instead of spreading ad-hoc shape checks.

Goal

Adopt Zod at important input/config boundaries and sweep the codebase for places where schema validation would simplify or harden parsing/defaulting.

Suggested scope

• Start with persisted local config, especially openkhodam-config.json.
• Define schemas for config shape, defaults, and safe partial/corrupt config handling.
• Keep filesystem mechanics separate: atomic writes, file permissions, and ENOENT defaults should remain explicit.
• Sweep renderer/main/preload boundaries for manually validated unknown data that would benefit from Zod.
• Avoid converting simple trusted internal types just for the sake of using Zod.

Acceptance criteria

• Clear recommendation for where Zod should and should not be used.
• At least the persisted OpenKhodam config path has a concrete migration plan or implementation.
• Manual normalization utilities are simplified where schema validation gives better safety/readability.
• No renderer access to sensitive token fields is introduced.

Notes

This is intentionally follow-up work; PR #26 can keep the current explicit config store implementation.

[khodam666]

2026-07-09 update from PR #79 discussion

PR #79 added workspace-scoped OpenCode model selection to openkhodam-config.json. We decided not to add Zod in that PR, but the new config shape makes this issue more concrete, especially if we later migrate durable config to SQLite.

Current relevant call flow:

renderer useOpenCodeModels
-> preload IPC get/setOpenCodeModelSelection
-> main ipcMain handlers
-> OpenKhodamConfigFileStore
-> JsonConfigFile read/write
-> openkhodam-config.json

Recommended future Zod approach:

• Add zod as an explicit @openkhodam/desktop dependency before importing it.
• Start at the persisted app-config boundary: packages/desktop/src/main/integrations/openkhodam-config.ts.
• Define schemas for the full app config, not only the new model-selection subtree:
  • projects.openedFolders
  • preferences.openCode.modelSelectionsByDirectory
  • integrations.googleWorkspace.account/scopes/token/updatedAt
• Keep JsonConfigFile focused on filesystem mechanics: ENOENT default, atomic temp-file write, file mode, and JSON parse/write. The store should provide schema-backed normalization.
• Preserve current forgiving config behavior. Bad or stale optional entries should be dropped/defaulted rather than making app startup fail.
• Keep path canonicalization and safety rules as domain logic outside Zod. Zod should validate object/string/number/null shape, while helpers still handle realpath checks, absolute path checks, null bytes, safe artifact paths, and secret-like URL filtering.
• Use separate schemas for persisted data and IPC inputs when behavior differs. Persisted config should be tolerant; IPC mutation inputs can fail fast with clear errors.

Suggested implementation sequence:

1. App config first: replace most isRecord object-shape checks in openkhodam-config.ts with schema-backed normalization while preserving existing tests and behavior.
2. Add or adjust tests around corrupt/partial app config, invalid model selections, stale directories, and Google token/account defaults.
3. Consider project artifacts in a follow-up: packages/desktop/src/main/integrations/project-artifacts.ts has more domain-specific rules and should not be converted mechanically.
4. Only after the schema boundaries are stable, use those schemas as the migration contract for a future SQLite-backed store.

Why not convert everything at once:

• openkhodam-config.json is a straightforward app config boundary and is the best first target.
• .openkhodam/artifacts.json includes dedupe/merge behavior, timestamp reconciliation, safe relative artifact paths, and URL secret stripping. Zod can help with shape, but the domain normalization still needs explicit helpers.
• Google Docs artifact JSON files are mostly write-side trusted app data today, so they are lower urgency unless the SQLite migration includes those artifacts.

Acceptance criteria to add to this issue:

• openkhodam-config.json has a concrete Zod schema and tolerant normalizer.
• IPC get/set model-selection inputs are validated with clear errors.
• No Google token fields are exposed to the renderer.
• Existing config tests continue to pass, including PR Add provider onboarding and model persistence #79 model-selection persistence/fallback coverage.
• The resulting schema can be reused or referenced by a future SQLite migration plan.

[khodam666]

Effect migration coordination

The broader Effect migration is now tracked in #97. The initial config-persistence pilot should preserve the current tolerant normalizer rather than combine runtime conversion with a schema rewrite.

Once compatibility and corrupt/partial-config tests are established, this issue should decide the schema boundary deliberately:

• compare Effect Schema with the proposed Zod approach;
• select one persisted-config validation strategy rather than maintaining duplicate schemas;
• keep filesystem mechanics in JsonPersistence and domain/path safety outside generic schemas;
• preserve forgiving legacy decoding and ensure token fields never cross into the renderer;
• use stricter schemas for IPC mutation inputs where appropriate.

This makes schema adoption a follow-up to the persistence pilot, not a prerequisite or an accidental second validation framework.