server/claude-sdk.js (1)

44-53: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low value

Add optional chaining on OPTIONS lookup.

If modelsDefinition is a truthy object without an OPTIONS array (e.g. a malformed catalog returned by the provider models service), modelsDefinition.OPTIONS.find(...) throws. This is currently caught by the outer try/catch in queryClaudeSDK, so it degrades to a failed query rather than a crash, but a defensive ?. would avoid an unnecessary user-facing failure for malformed catalog data.

🛡️ Suggested defensive tweak

 function resolveClaudeEffort(model, effort, modelsDefinition = CLAUDE_FALLBACK_MODELS) {
-  const selectedModel = modelsDefinition.OPTIONS
+  const selectedModel = modelsDefinition?.OPTIONS
     .find((option) => option.value === model) || null;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@server/claude-sdk.js` around lines 44 - 53, The model lookup in
resolveClaudeEffort assumes modelsDefinition.OPTIONS always exists, which can
throw for malformed catalog data. Update the OPTIONS access in
resolveClaudeEffort to use optional chaining before calling find so a missing or
invalid OPTIONS array safely falls back to null/undefined. Keep the effort
validation logic unchanged and make sure the fix is localized to
resolveClaudeEffort.

src/components/chat/view/ChatInterface.tsx (1)

19-22: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Effort fallback values duplicated across files.

FALLBACK_COMPOSER_EFFORT_OPTIONS repeats the same literal ['low', 'medium', 'high', 'xhigh', 'max'] / ['low', 'medium', 'high', 'xhigh'] lists as FALLBACK_EFFORT_VALUES in useChatProviderState.ts. Keeping two (likely three, counting backend fallback definitions) copies of the same effort tiers risks drift if a tier is ever added/removed. Consider extracting a single shared constant.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/chat/view/ChatInterface.tsx` around lines 19 - 22, The
fallback effort tier lists are duplicated in ChatInterface and the chat provider
state, so update FALLBACK_COMPOSER_EFFORT_OPTIONS to use a shared source of
truth instead of hardcoded literals. Extract the common effort tiers into one
shared constant/module and reference it from both ChatInterface and
useChatProviderState so the values stay aligned if tiers change.

src/components/chat/hooks/useChatProviderState.ts (1)

309-334: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Redundant localStorage read duplicates currentEffort.

reconcileStoredEffort re-reads localStorage.getItem(storageKey) instead of just using the currentEffort parameter that was passed in. Since currentEffort (the React state) and the localStorage value are kept in sync by setStoredProviderEffort and by this same reconciliation effect, the two should always match — the separate storedEffort lookup appears to just duplicate currentEffort. Consider simplifying to operate on currentEffort alone.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/chat/hooks/useChatProviderState.ts` around lines 309 - 334,
The reconcileStoredEffort callback is redundantly reading from localStorage even
though currentEffort already represents the same persisted state. Update
reconcileStoredEffort in useChatProviderState to operate on currentEffort alone,
removing the extra storageKey/localStorage.getItem path and keeping the
allowedValues checks and DEFAULT_EFFORT_VALUE fallback behavior intact.

src/components/chat/hooks/useChatComposerState.ts (1)

166-176: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Direct localStorage read for effort duplicates the reactive prop.

getLatestProviderEffort re-reads ${provider}-effort from safeLocalStorage instead of using claudeEffort/codexEffort directly, even though those props are already part of handleSubmit's dependency array and should be current at submit time (since setStoredProviderEffort updates both state and localStorage synchronously). This adds an extra access path that must stay consistent with the hook's own state, increasing the surface for drift without a clear functional benefit.

Also applies to: 748-753

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/chat/hooks/useChatComposerState.ts` around lines 166 - 176,
`getLatestProviderEffort` is redundantly reading `${provider}-effort` from
`safeLocalStorage` instead of using the already reactive `claudeEffort` and
`codexEffort` values available in `handleSubmit`. Update the
`handleSubmit`/effort resolution path to rely on the hook state props directly,
keeping the existing fallback behavior for non-Claude/Codex providers, and
remove the extra localStorage access so the logic stays aligned with the
dependency-tracked state.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes