fix: add runtime validation for PermissionTier settings value

[Cheezeiii365]

Summary

PermissionTierBadge uses as PermissionTier to cast the value from getResolvedSettings() and onSettingsChanged() without runtime validation. If an invalid value reaches the component, TIER_CONFIG[tier] returns undefined and the render crashes accessing .className.

Additionally, the initial getResolvedSettings() promise has no .catch() handler.

File

packages/renderer/src/components/chat/PermissionTierBadge.tsx — lines 14–23

Current behavior

window.api.getResolvedSettings().then((settings) => {
  if (settings?.['agent.permissionTier']) {
    setTier(settings['agent.permissionTier'] as PermissionTier)
  }
})

The as PermissionTier cast bypasses type safety. If a corrupted or hand-edited settings file contains an invalid tier string, TIER_CONFIG[tier] is undefined and the component throws on render.

Expected behavior

• Validate the value against known tier keys (e.g., value in TIER_CONFIG) before calling setTier
• Add .catch() to getResolvedSettings() to handle IPC failures gracefully
• Apply the same validation in the onSettingsChanged callback

Suggested approach

Keep it simple — an inline if (value in TIER_CONFIG) check is sufficient. No need for a standalone type guard function.

window.api.getResolvedSettings()
  .then((settings) => {
    const val = settings?.['agent.permissionTier']
    if (val && val in TIER_CONFIG) setTier(val as PermissionTier)
  })
  .catch(() => { /* keep default tier */ })

Priority

Low — the settings value is controlled by the app's own UI/logic. The only realistic trigger is manual JSON editing of the settings file.

Labels

• fix
• low-priority